I'm using hg even with github. The hg-git extension from the github guys works surprisingly well for me. The only downsides I've found that push/pull of very large repos tends to be a bit slow and the conversion to/from git will clobber file move histories in hg, since git doesn't track file moves.

> That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.

Considering more people know git I would assume the training cost for hg is higher.

More people use git; I'm becoming increasingly convinced that few of them actually know git.

> More people use git; I'm becoming increasingly convinced that few of them actually know git.

And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.

> And yet I have noticed that people find merging and branching much easier than in mercurial.

That's the first time I've heard this opinion - do you know what kind of complaints people have?

In my experience, it's much easier to say 'When you start work on an issue, start a branch called 'issue-XXX', then once you're done we will merge it into the default branch'. I've never seen much confusion in response to that.

Yeah, named branches in hg are just weird.

Not as weird as hijacking the term "branch" to mean a symlink to a ref that is not part of the history. Then again why make it easier by naming it to something more intuitive, like say, "bookmark".

Because a bookmark is usually immutable. If I bookmark "https://hackertimes.com/ has "Hacker News" it will be same URL forever.

In contrast, git branches symlink to a different ref, whenever you commit to it.

A git tag could be called bookmark intuitively.