It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader.
That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial.
You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.
I’m not saying Git is perfect but simply that it’s hard to separate the difficulties from learning new concepts and working styles from the tool.
There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened.
If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.
Anecdote follows!
I originally started with cvs, and then later, svn. I struggled when git came along, the workflow felt super cumbersome and I kept tripping over the 3 stage process (working directory, staged for commit, and committed), compared to the 2 stage process for already-tracked files in cvs and svn.
After several years, I still never got used to it, and kept having to google when I’d run into random weird issues, having accidentally gotten my repo into a state that had strayed from the basic happy path. Then I started using hg at work, and life got a whole lot easier.
I still haven’t migrated my personal repos off git into hg, mostly because I haven’t (looked for, or) found an hg equivalent of gitea that I can self host, but from my personal experience, day to day usage of git is way harder than day to day usage of hg.
Then again, it helps that I learned hg on the company dime, instead of on my own time.
No. I had used CVS, SVN, SVK, Bazaar, and Mercurial for years before I switched to Git. I can generally explain the internals of all of these tools (a DAG) to someone in simple terms in minutes. Overlaying that onto the commands becomes easy.
What Git does is take that concept and wrap it in the worst possible workflow UI. The people that immediately grafted onto the Git community cheered this on for some reason very early and then recanted by saying that you are really supposed to build "porcelain" for Git since it was meant to be a rough tool.
To this day all I see are articles about people's confusions and conniptions over simple things that Git does incorrectly because it's UI is horrible. Most can't even get to the point where they understand the DAG. Even though I know what is supposed to happen it's hard for me to fumble around with simple commands because the naming is inconsistent and I have to research to find solutions. This was rarely an issue with Mercurial and when I talk to people that have used both they seem to share that sentiment.
Git is the PHP of version control. Widely used and very popular but has a lot of architectural problems that make it a total mess.
We recently adopted a tool that uses Perforce as a backend. It's been interesting to try and describe centralized version control to younger engineers who have only used a dcvs like git.
Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?
Count yourself lucky then. Git was well known for losing data, so much, that it was featured at xkcd [1]. Well, perhaps not the tool itself, but it's user interface was (more than it is now perhaps) so awkward that users often got it wrong. If you don't make that back-up, you might not even know how much you've lost.
I’ve worked in modest sized teams within a larger organization (roughly a hundred developers) and have often been the person people ask for help when something goes wrong; most of our teams went from CVS / Source Safe to Subversion, and then Mercurial to Git, and the big step was really the switch to a distributed system - moving from Hg was largely a non-issue (things got faster, we liked GitLab more for other reasons). The only time Hg lost data was back in the era when rebase was an extension, so it wasn’t the core system’s fault but it was a source of friction.
