Your comment is criminally low. Every other comment is 'Git vs. Mercurial' and speculation as to why git has "won". Their not useless, but they are uninteresting technically. So, as a git aficionado, I thank you for a detailed analysis of Mercurial and this proposal.

Personally, I've only used Mercurial to check out some projects that use it exclusively (i.e. (previously) Python and Firefox) and to create a toy repo of no significance (to learn its CLI interface).

Just to highlight a couple things from your comment:

> Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

By far the most annoying thing about going from git to mercurial is the overloaded concept of a 'branch'. I couldn't care less about the continued existence of my one-off, topic branch. TBH, I prefer the git concept of the reference pointer being culled in the process. The (git) branch's existence continues on only in the merge commit message. Although this assumes 1) an actual merge was committed (not rebased), 2) the merge wasn't fast-forwarded (--no-ff), and 3) the default merge message format was used.

> With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”.

> Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

We use Github. IMO, Github made a HUGE mistake when they added the options to Rebase and Squash in-lieu of the only sane option, Merge. I suspect that a lot of users wanted these options because Github (still) refuses to drop the --no-ff from their Merge strategy. I prefer --no-ff, but I do agree that it does make for an ugly log graph; Unlike most people, I couldn't care less about pretty graphs.) Rebase and Squash shouldn't be considered "Merge" strategies. They're for cleanliness, but only prior to sharing changes. Having them in Github has made the process of figuring out what has (and hasn't) been merged just absolutely atrocious. I'll leave it at that, but needless to say my arguments haven't convinced my peers' desire for pretty graphs.

As far as other user comments, I think the most egregious suggestion has been (paraphrasing):

> Mercurial has (had) better documentation.

Which I think is patently false. Git' manpages are (and always have been) fantastic. git-scm.com has been around for as long as I can remember. If you really want to do so, you can get yourself deep into the git's technical documentation which will teach you everything about the file formats and algorithms that are being used. All of this documentation has been around since git maintenance was handed over to Junio Hamano (circa May, 2005); Long before it's popularity explosion.