I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).
Performance is such an important advantage, though.
I type git diff hundreds of times a day, and when I switched from hg to git at Mozilla, this made such a big difference in my life.
These days I type hg histedit maybe fifty times a day at Google, and I cry every time because it is so. glacially. slow. hg diff too. And I'm working with a relatively small repository.
Speed matters for tools we use all the time.
I'd also posit that the process of writing "plugins" for git is much easier than writing hg plugins. A git "plugin" is just a shell script that uses git. If you can use git, you can write a shell script that uses it. An hg plugin...whoaboy.
$ time hg help > /dev/null
real 0m0.232s
user 0m0.196s
sys 0m0.033s
$ time chg help > /dev/null
real 0m0.081s
user 0m0.003s
sys 0m0.000s
$ time hg diff
real 0m1.383s
user 0m0.558s
sys 0m0.333s
$ time chg diff
real 0m1.224s
user 0m0.003s
sys 0m0.007sWhich I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.
So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).
I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...
I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!
That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.
I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.
For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.
Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.
That's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.