I find it strange that he calls msysGit a good solution on Windows.<p>My personal Windows machine has Cygwin, MSYS (for MinGW), and MSVC's own command line (based on cmd.exe), so that I can use each of those three compilers for compatibility testing my projects. With msysGit my experience has not been good at all; patching git into each of the evironments always seems to require some manual work on my part, despite msysGit's claim that it can put just the git binaries on PATH.<p>So quite frankly, I do not think the current Windows situation for git is adequate, as it has (in my experience) integrated poorly with various command line environments.
<i>>My recommendation to other people facing similar decisions is to choose the project that has a brighter future, chances are the “disadvantages” you see in the present would be resolved soon enough.</i><p>That's not what I would recommend at all. There's no guarantee a project will resolve those issues or that new ones will crop up. Google was correct in choosing hg because it was the best choice <i>at the time</i> (back in 2008).<p>It looks like his only positive point are the branches, and then goes on to say, "The conclusion shouldn’t be that surprising; Git wins." I'd imagine hg being supported in Windows without requiring a third party install is a big plus.<p>I think the first comment puts it nicely: <a href="http://gitvsmercurial.com/" rel="nofollow">http://gitvsmercurial.com/</a><p>----------- edit -----------<p>It looks like the author had a discussion in the comments:<p><i>>My objective is to show why Git is superior. So if you care about your own performance, and the one of your project, the choice is obvious. One allows you to do many things, the other one doesn’t.</i><p>However, this contradicts his previous statement that the differences between the two are subtle and only proves his bias is heavily influencing his conclusion.
Let us not forget that GitHub is a <i>major</i> reason why people choose Git. If Bitbucket (or a hypothetical HgHub) had taken the larger market share first, we'd likely see more projects using Hg than Git.
Mercurial having an extension to make their branches like git is exactly why Mercurial is superior. I love git branches, but everything else about it is worse, but that's OK because I just use the extension like everyone else. Mercurial has great extensibility, which means if you need to do anything not simple, it lets you.<p>As they say, simple things should be simple, complex things should be possible. Mercurial is the best of both worlds.
To me, it's obvious that the author has entered the comparison with a very strong git bias, so it is only naturally that git won eventually.<p>He is right on one thing: the differences are mostly subtle, the most glaring one being whether history is allowed to be rewritten or not. In the end it all comes down to personal preferences, and my personal experience is strongly in favor of hg.
This was a really bad comparison/argument for git. Anyone actually trying to decide between the two should just forget everything you've read and start with a different source.<p>That aside, I've used both over the last 3 years (2 in git; 1 in hg) and although I prefer git, hg is a fantastic tool. I think the largest difference between the 2 is usability. I do believe hg is quite a bit easier to pick up. It does a really good job of, by default, making sure you don't shoot yourself in the foot and also keeps you further away from the 'nitty-gritty'. Git, on the other hand, allows you to do whatever you want and generally makes the assumption you always know what you're doing. The details are not very far down from the surface and it's easy to get yourself in trouble if you don't know what you're doing.<p>Personally I prefer git because I feel so close to the metal, but there's certainly a perfectly valid argument to choose hg over git.
Felipe Contreras, do you really not see your bias at selecting the example you chose? Paragraphs before you mention how in Mercurial "History is Sacred" then you push for that.