Why a small team chose Mercurial.

This misconception always bothers me:<p>"In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do."<p>Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental difference here.<p>I don't want every failed, unbuildable, safety-net commit making it into my project history. I want it to be possible for people to understand change.<p>For example, here are the last few commits from my primary work project: <a href="http://pastebin.com/BiNpP08s" rel="nofollow">http://pastebin.com/BiNpP08s</a><p>In a week from now, will you need to see the four different attempts it took to get that last change right? If so, you can always follow the code review link and see the discussion that went on there and how it shaped into that file change, but anyone who makes actual good use of their project history will get frustrated pretty quickly at thought-free changes.

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches.<p>Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way to do this in hg. [1] Deleting a branch is not a fundamental concept in hg, and so the advice is to create a new local "clone" of the entire repo. [2] Great, now you have to change the config files for your dev environment to point to a new folder just so you can test out crazy feature. Also, by default all your branches get pushed (although hg will complain about creating remote branches).<p>In practice, all this turned "branching" into an expensive concept in my mind. That's bad, very bad.<p>I still prefer the hg elegance and ui to git -- even the output of "hg st" vs "git status" tells a great deal about the philosophy behind both. However, I think hg got branching wrong and that is a fundamental flaw that no amount of elegance at the UI level can compensate for.<p>I remember when I was making my first choice between hg and git and the advice was "they're pretty much the same, pick one." I think that advice is incorrect based on what I've said above.<p>[1] <a href="http://mercurial.selenic.com/wiki/LocalbranchExtension" rel="nofollow">http://mercurial.selenic.com/wiki/LocalbranchExtension</a> [2] <a href="http://mercurial.selenic.com/wiki/PruningDeadBranches" rel="nofollow">http://mercurial.selenic.com/wiki/PruningDeadBranches</a>

Before this devolves into a git versus hg holy war by people who never read the linked blog post, I'll point out that they chose hg over svn. It's mainly a cheerleader piece for DVCS with the git versus hg choice being a minor point.

Pretty good; liked that they didn't just say "HG GOOD, GIT BAD". I'm confused about the git learning curve though; I started using git on my own this summer, and I was able to immediately pick up the commands I needed to get by literally the day I started. I'll admit I don't have to host repositories, like they would in for their company; but for simply using git as a developer it was very painless.

altogether a means to an end, mercurial and git are both good. i personally use mercurial. have worked with git in the past and was having trouble with the gerrit web front end and the fact that it required java.<p>i also use bitbucket and since having been bought by atlassian, was able to get lots of free private repositories. i think some people mentioned that they accidentally left cookie secrets in their code on a public github project.<p>i'm still too early in development to get into the perceived branching woes that others are talking about, but i'll let you know when i get there.