Hg versus Git – and why I did chose Hg

After my unpleasant experience with setting up Git, I’ve had some time to play around with Git and use it in a project. Git is really nice for a DVCS. What I like was the git status view, especially with colors turned on. Grouping added and modified files is much nicer than the Subversion style “A”, “D” (…) list. What I also like is that Git is fast. And not very difficult to use for day-to-day jobs, with tutorials like the Svn-Git Crashcourse. Killer features for Git are git rebase and especially branching. Git is different to other VCS that it uses revisions and branches as views to a directory. Other VCS – like HG and SVN – use different directories for different branches. This makes it much harder to jump between those branches. Git seems to have the biggest community, mindshare and momentum to become the next SVN/CVS.

What made it unusable for me was the Windows port. It just does not work reliable. Cygwin is a problem in it’s own. Msysgit isn’t up to par neither. I use a MacBookPro so Git works for me, but others who needed to access the repo from Windows were out of luck. Windows support isn’t very high on the list of Git priorities – perhaps because it’s linked to Linux kernel development.

Now to Mercurial. It seems to have the second biggest mindshare (more than bzr) after Git. Some big Java projects use it and there are some good blog posts about Mercurial. So I gave it a try. The setup was easy for a central server over http, it just worked after following the instructions. It’s command style is more like SVN than Git so the learning curve is even shallower than with Git. It works with Windows, the main reason for me the switch to Hg from Git. The downsides: SVN style hg status, no rebase and SVN style branches. Nice that hgignore is just a file in the repo and accessible by all developers (Maven target and generated files).

Should Git become usable under Windows, I’ll probably move again.

(My personal take is, SVN will become a DVCS by adding local repos, moving to hash revisions and eat the DVCS market)

Thanks for listening.

Update: I forgot about that post:

For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again.

You can leave a Reply here. Of course, you should follow me on twitter here.