Why a small team chose Mercurial.

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.

This misconception always bothers me:

"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."

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.

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.

For example, here are the last few commits from my primary work project: http://pastebin.com/BiNpP08s

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.

The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history.

The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history.

If you just need to save some partially working state, etc. you can use patch queues- They make much more sense here.

Having taught people both systems, I will assert, based on my personal experience, that while some developers can certainly pick up Git relatively painlessly, picking up Mercurial objectively requires less time, and leaves users less likely to get into a state that they are unsure how to exit. This is purely based on my own personal experience, and I have not scientifically codified the learning time in double-blind testing or whatnot, but it's a data point based on more than just my own personal meandering attempt to learn the two tools.

EDIT: I am not making a value judgment here. It's harder to learn to fly a plane than drive a car, but that hardly makes the car better than the plane or vice-versa. It's just a recognition that their learning curves aren't identical.

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.

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.

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.