IIUC, Mercurial added support for git-style local branches just recently, in version 1.1. Mercurial calls them "bookmarks".
justin
· 10 months ago
Wow! That's pretty great. All these advantages that go to git are quickly fading away.
Peter Arrenbrecht
· 10 months ago
I am not quite sure this is correct. I believe git-style local branches don't automatically get pushed, whereas Mercurial's do unless you're careful. We're currently looking into having such truly local-only local branches in Mercurial which you'd have to explicitly push/pull.
Ian Lewis
· 10 months ago
While with big repos this is a bit of a pain, mercurial local branches can accomplished by simply cloning locally.
hg clone . ../my_local_branch
Wm Tanksley
· 10 months ago
As a committed Mercurial user and fan, I have to admit: well said. Git does many things better. Right at the moment Mercurial is better on Windows, so any cross-platform project needs to carefully weigh the options, but I find Git's current feature set to be more capable.
Also notable... Although Mercurial's historical refusal to deeply support history rewriting is well-principled and reasonable, Git's support for it is actually sensible given Git's architecture. It turns out that while Mercurial is built on the idea that a version control system should remember differences (and reconstruct the actual files), Git is built on the idea that a version control system should only remember files (and store differences only to save space). Thus, when you edit a Mercurial history you're forcing Mercurial to alter the most important data it has; when you edit a Git history you're merely changing some files (usually only removing files), no different (in principle) from checking in a branch.
Mercurial's architecture makes perfect sense, and gives it a huge head start in speed and size; but Git's architecture really does preserve the things that matter most (the actual files), which makes inherently risky things like rewriting history relatively risk-free.
Thumbs up to Git for a flexible and sensible architecture.
I'm still using Mercurial for its superb Windows support (sorry, guys, gotta use it); but I'm keeping my eye on Git. (By the way, aside from extreme slowness, Git also hasn't gotten git-svn working reliably on Windows -- at least not while I've been watching.)
Chris
· 10 months ago
Good post, but I'd like to point out that Bitbucket has no in-place editing / committing nor a Network Graph for seeing activity among forks. These are two of GitHub's most important features, so I think the "matches feature for feature" bit may not be entirely accurate.
Bitbucket also does not have commit commenting, another huge GitHub feature.
As you say though, Bitbucket does have features GitHub lacks (like the hg-powered wiki - GitHub's is not git powered) and issue tracker. The two sites take different approaches to patch management as well (patch queue vs fork queue).
Both sites have many similar features but it's unfair to call them equivalent as each has useful, unique features the other lacks.
justin
· 10 months ago
Perhaps I was a bit too abrupt. I understand that they both have unique features that draws some distinction between the two, but bitbucket and github are close enough (in my mind) to make the existence of a central place for people to coordinate on code a non-issue in choosing between the two.
I think it would be pretty cool if they could merge and allow you to choose between using hg or git for a project. That would help the social aspects without (hopefully) hurting any of the technical ones.
Ian Lewis
· 10 months ago
These features are absent. You are right. But at the end of the day, forks and pull requests are the truely important features of github/bitbucket.
I can live without the other stuff though they would be nice.
In place editing/committing is something I would probably never ever ever do. I like to test that a change works before commiting it. Maybe for documentation it would be ok, though lots of documentation is generated and you would probably want to make sure it looks the way you want it to before committing.
Loïc d'Anterroches
· 10 months ago
And at the end of the day, you are stuck with a closed source infrastructure like github that can kick you out the way they want. Github is nice, but you lose the principle of a distributed system by just putting everything in the same bucket. How sad... I am working on InDefero http://www.indefero.net to avoid that, I can use Mercurial and Git and stay independent from those services we don't know if they are going to be here tomorrow.
justin
· 10 months ago
I'm not sure I agree with you there. You don't really lose anything by using github and instead just gain their very cool features. If github bites the dust tomorrow, you still have all your cloned repos in tact on your own machine, you'll just have a much harder time coordinating with other people on the project.
Loïc d'Anterroches
· 10 months ago
This is the problem, you are locking yourself into a system for your code development where you depend on the good will/good health of a company. All your workflow you have slowly developed over the time is then lost, this is really a big blow for a project. Basically you still have the code, sure, but everything around can be lost from one day to another. Don't tell me, these one are good, they will not do that, etc. because just count the number of "cool companies" which failed or were bought back by a bigger one and then screw up everything. When you do go with a closed source service provider, you need to take that into account, if not, you cannot come later and say "If I knew..."
Augie Fackler
· 10 months ago
If you like hg, take a look at hgsubversion - it aims to do much the same thing as git-svn while letting you stay in hg.
justin
· 10 months ago
HgSubversion looks pretty cool. I'm excited!
I had tried hgsvn, which didn't really support pushing. It looks like this isn't quite ready for production use, but I'll be keeping an eye on it for when it is. This is definitely a big step for Mercurial.
It looks like you're one of the contributors? If so, thanks a lot for working on this! This makes Mercurial that much better.
Hatem Nassrat
· 10 months ago
I had a similar experience. I still think git is cumbersome to use, but I do truly think it is better designed that mercurial. Using merqurial queues to do thinks the git way is to cumbersome. I think soon I will move to git. The only thing I will miss is "hg serve", I wish there was a quick way to do that with git cause I *HATE* gitk from the bottom of my heart.
gebi
· 10 months ago
a short alias for your gitconfig: [alias] serve = !sh -c 'git daemon --reuseaddr --verbose \"$@\" --base-path=. --export-all ./.git' sh
Hatem Nassrat
· 10 months ago
Thats not exactly what I wanted. I completely forgot that hg serve is a way of casual sharing of the repo :). However, I meant "hg serve" in the sense of seeing changesets and looking at graphs and merges from the web.
justin
· 10 months ago
I agree, hg serve is marvelous.
I truly cannot pick which one I like more, but it took me a long time to get to the point where I could even admit that git was good. At first, its poor documentation and wretched user interface just completely turned me off. Having fixed that (mostly) and added support for SVN, I'm willing to admit that it's pretty good.
Hatem Nassrat
· 10 months ago
I do not know how I typed that, my English usually ain't that bad. :)
Matthieu Moy
· 10 months ago
gitk is ugly, but very powerfull and well designed, indeed. And nice alternatives exist in the GUI world (qgit, Giggle, ...)
If you insist in doing it from a web browser, try git instaweb. It's probably more hacky than "hg serve" in the implementation, but it does work too.
Hatem Nassrat
· 10 months ago
I am not sure what you mean by well designed, I get lost in it everytime I open it. I don't only hate it cause its ugly, its altogether unusable. I'd rather have them spent the time developing something like hg serve.
sean grove
· 10 months ago
I haven't had a chance to use Mercurial quite yet, though your Mac analogy tempts me. I've been using git and github for some time now, and it's been a slick experience overall/ Like you said, quick local branching is probably one of the best features.
That said, I'll give mercurial a try for my next side-project - always a good idea to at least try out new systems.
segv
· 10 months ago
Have you ever tried hgsubversion? It works similar to git-svn and is just awesome. you can also have local branching using the Bookmark extension in Mercurial 1.1 or later which gives you nearly the same power as git branches for local stuff.
Tim MacEachern
· 10 months ago
I'm using hgsvn for Mercurial/Subversion work. Create the combo SVN/Mercurial repository using hgimportsvn/hgpullsvn. Then clone a working Mercurial repository from that, using patches (hg qinit, qnew, etc.) for your work. The working repository can be updated by popping your patches, doing a pull, then repushing your patches. The hgsvn docs I've seen don't say how to push back work. I do that by starting a patch queue on the combo repository as well (hg qinit), then apply the work patch to the combo using this sequence: hgpullsvn (check for and get any updates from the main SVN repository first) hg qimport ../path/to/your/patch/patchname.patch hg qpush svn stat (make sure you like what you see) svn commit hg qpop svn revert -R . (remove the patch effects so you can do hgpullsvn again) hgpullsvn (refresh the combo svn/hg repository) hg qdelete patchname.patch
Then, on to your working repository, do: hg qpop -a hg pull -u hg qdelete patchname.patch hg qpush -a
justin
· 10 months ago
I tried to do this for a while, but it's a giant pain. git-svn is way easier, though from what I hear, hgsubversion might do the same for Mercurial.
Andy
· 10 months ago
I have a very similar story.
I switched to git for git-svn until hgsubversion came out and originally I did not like git much either. I like the mercurial documentation and philosophy. Git grew on me a lot for exactly the reasons listed: extremely cheap local branching and ability to edit history. The bookmarks extension is touted as enabling git-style branches, but I haven't found it to work that way in practice at all.
Editing history in mercurial drove me to learn mercurial queues, and now I'm totally addicted to patch queues. mq is also very polished and is a joy to use. It's actually the only thing that keeps me on mercurial. I've looked into patch queues for git, but none of the implementations suit me. StGit makes the index unusable and TopGit is to heavyweight for my development workflow (it's more built for package and patch maintainers). I like the semantics of Guilt (especially the interaction with branching) but it's kinda busted on macs, as all the development has been done on linux machines.
Aaron
· 10 months ago
I love git, and the fact that it's blessed by Linus means it's not going anywhere anytime soon. In fact, I'd put money on the fact that git will become the defacto standard in VCS.
justin
· 10 months ago
What about its lack of enthusiastic support for Windows? That's going to have to change for it to be the de facto standard.
Aaron
· 10 months ago
I don't care if git makes it to Windows or not, personally. I think it will, but really, it was developed by filesystem designers for distributed version control of the Linux kernel, so the focus is on Linux boxen. That's where the standard will emerge. Windows will probably do its own thing.
Hatem Nassrat
· 10 months ago
Have you seen tortoise HG, its an awesome piece of software. Although I hate something called windows, some of the people I associate with use it (I am going to have to drop these people soon though :) and I got them to love mercurial because of tortoise HG.
Now I hear they are working on the mercurial version soon though.
msysgit is the native (non-cygwin) port. And it's quite usable.
Tom
· 10 months ago
its also purely command line with a bash-like shell. How many windows developers have you actually worked with? they want their tortoise or vs integration not some hacky cli tool.
justin
· 10 months ago
msys is a smaller version of cygwin. They're both POSIX compatibility layers, and as such, I really don't like depending on them.
Wm Tanksley
· 10 months ago
That's not entirely accurate... msys is a set of libraries to allow POSIX applications to (sometimes) run on Windows. Its entire intent was to get rid of the "compatibility layer" problem with cygwin.
I'm not saying you SHOULD be using msys or git; but I am saying that using it is no worse than using any other large, multiplatform library. Certainly Qt would be no better, for example.
There are better reasons; for example, one might dislike the atrociously slow performance of git on Windows after seeing so many people advertise its speed as being one of its best features. Perhaps one might dislike its slapdash implementation in an odd mixture of bash, perl, and C. (And probably others.) I would share those dislikes.
All Comments
hg clone . ../my_local_branch
Also notable... Although Mercurial's historical refusal to deeply support history rewriting is well-principled and reasonable, Git's support for it is actually sensible given Git's architecture. It turns out that while Mercurial is built on the idea that a version control system should remember differences (and reconstruct the actual files), Git is built on the idea that a version control system should only remember files (and store differences only to save space). Thus, when you edit a Mercurial history you're forcing Mercurial to alter the most important data it has; when you edit a Git history you're merely changing some files (usually only removing files), no different (in principle) from checking in a branch.
Mercurial's architecture makes perfect sense, and gives it a huge head start in speed and size; but Git's architecture really does preserve the things that matter most (the actual files), which makes inherently risky things like rewriting history relatively risk-free.
Thumbs up to Git for a flexible and sensible architecture.
I'm still using Mercurial for its superb Windows support (sorry, guys, gotta use it); but I'm keeping my eye on Git. (By the way, aside from extreme slowness, Git also hasn't gotten git-svn working reliably on Windows -- at least not while I've been watching.)
For instance: http://github.com/mojombo/jekyll/network
Bitbucket also does not have commit commenting, another huge GitHub feature.
As you say though, Bitbucket does have features GitHub lacks (like the hg-powered wiki - GitHub's is not git powered) and issue tracker. The two sites take different approaches to patch management as well (patch queue vs fork queue).
Both sites have many similar features but it's unfair to call them equivalent as each has useful, unique features the other lacks.
I think it would be pretty cool if they could merge and allow you to choose between using hg or git for a project. That would help the social aspects without (hopefully) hurting any of the technical ones.
I can live without the other stuff though they would be nice.
In place editing/committing is something I would probably never ever ever do. I like to test that a change works before commiting it. Maybe for documentation it would be ok, though lots of documentation is generated and you would probably want to make sure it looks the way you want it to before committing.
I had tried hgsvn, which didn't really support pushing. It looks like this isn't quite ready for production use, but I'll be keeping an eye on it for when it is. This is definitely a big step for Mercurial.
It looks like you're one of the contributors? If so, thanks a lot for working on this! This makes Mercurial that much better.
[alias]
serve = !sh -c 'git daemon --reuseaddr --verbose \"$@\" --base-path=. --export-all ./.git' sh
I truly cannot pick which one I like more, but it took me a long time to get to the point where I could even admit that git was good. At first, its poor documentation and wretched user interface just completely turned me off. Having fixed that (mostly) and added support for SVN, I'm willing to admit that it's pretty good.
If you insist in doing it from a web browser, try git instaweb. It's probably more hacky than "hg serve" in the implementation, but it does work too.
That said, I'll give mercurial a try for my next side-project - always a good idea to at least try out new systems.
hgpullsvn (check for and get any updates from the main SVN repository first)
hg qimport ../path/to/your/patch/patchname.patch
hg qpush
svn stat (make sure you like what you see)
svn commit
hg qpop
svn revert -R . (remove the patch effects so you can do hgpullsvn again)
hgpullsvn (refresh the combo svn/hg repository)
hg qdelete patchname.patch
Then, on to your working repository, do:
hg qpop -a
hg pull -u
hg qdelete patchname.patch
hg qpush -a
I switched to git for git-svn until hgsubversion came out and originally I did not like git much either. I like the mercurial documentation and philosophy. Git grew on me a lot for exactly the reasons listed: extremely cheap local branching and ability to edit history. The bookmarks extension is touted as enabling git-style branches, but I haven't found it to work that way in practice at all.
Editing history in mercurial drove me to learn mercurial queues, and now I'm totally addicted to patch queues. mq is also very polished and is a joy to use. It's actually the only thing that keeps me on mercurial. I've looked into patch queues for git, but none of the implementations suit me. StGit makes the index unusable and TopGit is to heavyweight for my development workflow (it's more built for package and patch maintainers). I like the semantics of Guilt (especially the interaction with branching) but it's kinda busted on macs, as all the development has been done on linux machines.
Now I hear they are working on the mercurial version soon though.
I'm not saying you SHOULD be using msys or git; but I am saying that using it is no worse than using any other large, multiplatform library. Certainly Qt would be no better, for example.
There are better reasons; for example, one might dislike the atrociously slow performance of git on Windows after seeing so many people advertise its speed as being one of its best features. Perhaps one might dislike its slapdash implementation in an odd mixture of bash, perl, and C. (And probably others.) I would share those dislikes.