Hacker News Reader

Never used mercurial. I suspect it's just as good, but the problem the author probably sees is, like me, most everyone is familiar with git and new hires need to be trained in something unfamiliar with less community around it.

View on HN

I wonder how large that friction is. I look at git, mercurial, etc as distributed version control first and foremost, and that they're more alike than different.

It could be that I witnessed the popular adoption of all this via Linux going from tarballs/patches/mailing lists -> bitkeeper -> git, and have used and witnessed-the-evolution-of rcs, cvs, subversion, various DSCMs, and so my concepts of source control are stretched more broadly than people that are experiencing the dissonance between (e.g.) mercurial and git.

Edit: clarifying words

If you are used to an "always branch" workflow, mercurial can impose a lot of friction.

Do you have anything you can point to for that friction? I'm always looking to do better than I already am and would be interested in understanding the issues here.

Used to work at Dropbox. Existing knowledge of new hires was 90% of the challenge with Mercurial with the other 10% being weird edge cases (e.g. very large/numerous repositories) that hadn't seen as much attention due to the smaller community.

Reply on news.ycombinator.com