> It is superior to Git in every way except performance and adoption.
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.
I'll see what I can do. Because it's Google code, it may not be feasible. But we have a whole team of hg developers ourselves, maybe I should bug them before putting it on you. :)
Please correct me if I'm wrong, but I think it was in "The Hundred-Year Language" [^1] where @pg argued for performance as a language design feature. He could have meant a different kind of performance though.
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.