Other than the 'Mercurial Advantages' section, which is nearly entirely incorrect, this is a pretty good overview of both systems. I can definitely see the HTTP transport support being a deciding factor for them, and the ability to hack in Python as opposed to C. However, the 'mercurial advantages' section should really be addressed.<p>1) Learning Curve. This section states that Git has more commands and is harder to learn. In fact, they both have about the same number of commands - run 'git' and 'hg' with no arguments and you'll see how similar the common commands listings are. Hg and Git both have 'plumbing' commands that can be used for lower level stuff (run 'hg debug' if you don't believe me) that are not meant to be used by normal users, but both systems have them. The documentation issue is pretty moot too - Git has tons of useful documentation and I feel the homepage (git-scm.org) is much easier to use and find helpful information on (though I could be biased because I created it). As to the 'command set is closer to SVN so people get confused less', I think that's actually unhelpful. Hg is not Subversion and thinking about it as a 'Subversion+' I think makes users even more confused when something doesn't work how it did in SVN. Now something didn't work right AND they have a faulty mental model of what it's supposed to be doing. Furthermore, the UI for Hg is not all roses and puppies - one of the first things you have to do, editing config files, has to be done manually and can be confusing and seemingly arbitrary. Both systems have good and bad points in UI and functionality, but unless you're basing your decision on the systems as they were two years ago, which this article seems to be, it's really difficult to effectively argue that Hg is really easier to use. For every thing someone can say is difficult or unintuitive in Git, I can list one for Hg. I have seen tons of people pick it up and be able to use it effectively in a single day. This is subjective hearsay, it is not a valid argument.<p>2) Windows Support. If you run TortoiseGit or Git Extensions, you will see that Git has moved ahead leaps and bounds in this department recently. Even the general MinGW port by itself works really well and has a nice installer.<p>3) Maintenance. They state that 'Git requires periodic maintenance of repositories (i.e. git-gc)' - this is just flat out untrue. Git runs this command automatically every once in a while - you do not have to do it yourself. This is actually pretty nice because it keeps your repository as small as possible, where Mercurials reflog format can bloat unnecessarily and there is no way to optimize it's disk usage.<p>4) History is Sacred. They say that "Git is perfectly happy to lose history.", which is incredibly untrue - in fact, it's pretty difficult to lose history in Git. They site that you can run '--force' on a push to overwrite history, but there are several ways to disable this on the server. To point out how little they seem to understand Git server concepts, they say: "It should be noted, however, that a custom Git server could be written to disallow the loss of data, so this advantage is minimal." All you have to do for this either a) add a simple pre-receive hook that simply doesn't allow non-fast-forward pushes, or b) run 'git config --system receive.denyNonFastforwards true' on the server, which will make Git ignore the '--force' client option. You don't have to write a "custom git server", you need to run one quick command.<p>I actually like parts of Hg. Given that Guido works there and there are a lot of python devs there and Hg has good smart http protocol, I'm sure it makes perfect sense to use it. However, spreading this sort of FUD about Git is not helpful to the DVCS ecosystem as a whole.