I’ve been a big fan of Mercurial for a while now. Harmonize is all kept in Mercurial, and most of my side projects are as well. Mercurial is great for a number of reasons. It’s easy to use, not only for former subversion users, but also at a conceptual level. Understanding how DVCSs work is easy when you’re using Mercurial. The vocabulary is sparse and makes a lot of sense. As added bonuses, it runs on Windows just as well as it runs on every other OS, and it’s written in Python (my favorite language).
However, I’ve decided to allow git into the very exclusive club of version control systems that don’t suck. Git makes two, and it might become my favorite as I get more comfortable with it.
To pause for a moment, one of the things git does not do better is github. Github has, perhaps, a slight advantage over bitbucket because of the size of the user base, but that doesn’t make it inherently better. It’s just a better social experience for now. From what I can tell, bitbucket matches github feature for feature and outdoes it in some areas. I’m a huge fan.
That being said, there are a few things git does better than mercurial. The first is editing commit histories. Mercurial supports a similar feature through extensions, but git has a leg up by coming with the ability to alter any part of your commit history built in. This allows things like cherry picking, merging batches of commits into one, and cleaning up commit logs. Mercurial can kind of do these things, but it’s much better supported in git. Plus, as a relative newcomer to git, I’m sure I haven’t even scratched the surface of what’s possible.
The second advantage that goes to git is local branching. Now let’s be clear here. Mercurial does support branching in much the same way git does. However, if you ever push to a remote repository, your branches must exist there or you must create them there. Local branches are nice because they don’t need to clutter up whatever master repository you have. You can have your own branches for whatever you’re up to and don’t need to mess with what the rest of the world is doing. I use this all the time and love it.
In the end though, there is one feature that has pulled me toward git and kept me there, and that’s git-svn. My current employer uses Subversion, and since that is not one of the version control systems that don’t suck, I quickly became agitated. I desperately tried to use Mercurial with SVN, to no avail. There is pretty good support for mirroring a SVN repository in Mercurial, but pushing back to svn quickly became a nightmare. I even found a script that did a pretty good job, but in the end, the support wasn’t there.
Git-svn, however, is a different story. It utilizes git’s amazing ability to manipulate commit histories to allow you to pull down changes from an SVN server, do your own thing, commit as much as you want in yout git repository, and then when you’re ready, push it all back to the SVN server. It’s incredible. I can do all the local branching I want, play with things, finalize a feature, whatever, and in the master branch keep up with the day to day bug fixes. When I’m ready, I just merge and push. Now I don’t even think about dealing with straight SVN. The first thing I do if I’m going to be doing anything beyond reading code is pull it into a fresh git repository. From there, I’m free to use version control as it should be used without bothering anybody else. At the end of the day, I can either push all my commits out, or modify them into a few larger, more well defined commits. I pretty much never fight with subversion anymore, and that makes me a happier person.
Despite what I’ve said here, I still love Mercurial. It’s such a simple and well designed piece of software that it makes me smile a bit. It’s like the Mac where git is like Linux. I work on Linux because I need the raw power, but at the end of the day, I really want a mac to be sitting there beside me. So make your own decisions, but at this point I’m willing to admit it. Git is awesome.