6 ms·

It would be interesting to read a breakdown of why Mercurial failed against Git. It is superior to Git in every way except performance and adoption. Git won bec

by pgt 7y ago

It would be interesting to read a breakdown of why Mercurial failed against Git. It is superior to Git in every way except performance and adoption. Git won because GitHub won, and I bet GitHub chose Git over Hg's Python implementation because it was too slow. I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).

nerdponx 7y ago
In my understanding it's the opposite, that Mercurial is effectively a subset of Git. But I was never a Hg user.
- andrewshadura 7y ago
  Well, you can express any Git repository in Mercurial terms, but not otherwise.
gpderetta 7y ago
> It is superior to Git in every way except performance and adoption. For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.
- simias 7y ago
  I'm not so sure really, in my experience the performance difference only becomes noticeable if you have a very large repository. For the Linux kernel I'm sure it matters, for "my library with 100 commits and 10k lines of code" it won't make a significant difference.
  - dbt00 7y ago
    Most commercial projects are orders of magnitude more complex than that, and the performance differences are stark.
  - newen 7y ago
    People are going to go for something that runs in 0.1 seconds as opposed to 1 second, most things being the same.
  - plorkyeran 7y ago
    I have worked on many projects where I have wished that git was faster. It doesn't take a very big repository for performance to become an issue.
microtherion 7y ago
Part of git's success might be due to its initial association with Linus. Which 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).
simias 7y ago
I'm reminded of that article I read on HN a few months ago about how "you're not Google/Amazon/Facebook" and you probably shouldn't base your technical choices on what these companies are doing because chances are that you have a massively different usage profile and very different priorities. Still, everybody wants to be like the big guys (dress for the job you want, not the one you have) so you still often seen small-ish websites using a ridiculously overpowered and over-architectured backend. 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.
- philpem 7y ago
  There are similar patterns in other industries. Manufacturing tends to fetishise the automotive industry -- so an absolute mountain of changes come from "well Toyota's doing it" or "well BMW is doing it". Of course, they're great solutions for building cars, but not so great when you're building TV remote controls. 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.
- gilrain 7y ago
  On the other hand, the software development version of the maxim "dress for the job you want, not the job you have" could easily be "use the tools the job you want uses, not just what you can get away with".
dragonsh 7y ago
Performance is not the reason GitHub chose git over mercurial. They chose git because their core developers understand internal architecture of git better. They were more proficient in Ruby and C than Python, so git was a natural choice for GitHub. 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.
jlebar 7y ago
> 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.
- durin42 7y ago
  Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.
  - jlebar 7y ago
    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. :)
    - ezst 7y ago
      well, you just addressed this message to the current lead maintainer of Mercurial, who happens to be a fellow co-worker of yours ;)
    - mambru 7y ago
      Including durin42 himself ;)
- pgt 7y ago
  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. - [^1]: http://www.paulgraham.com/hundred.html http://www.paulgraham.com/hundred.html
rimliu 7y ago
I have no idea how good mercurial is now, but I think back in the days when git started to get ahead it was superior to mercurial in more than one way.
rsynnott 7y ago
> except performance 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.

by pgt 7y ago

nerdponx 7y ago

In my understanding it's the opposite, that Mercurial is effectively a subset of Git. But I was never a Hg user.

andrewshadura 7y ago
Well, you can express any Git repository in Mercurial terms, but not otherwise.

gpderetta 7y ago

> It is superior to Git in every way except performance and adoption. For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.

simias 7y ago
I'm not so sure really, in my experience the performance difference only becomes noticeable if you have a very large repository. For the Linux kernel I'm sure it matters, for "my library with 100 commits and 10k lines of code" it won't make a significant difference.
- dbt00 7y ago
  Most commercial projects are orders of magnitude more complex than that, and the performance differences are stark.
- newen 7y ago
  People are going to go for something that runs in 0.1 seconds as opposed to 1 second, most things being the same.
- plorkyeran 7y ago
  I have worked on many projects where I have wished that git was faster. It doesn't take a very big repository for performance to become an issue.

microtherion 7y ago

Part of git's success might be due to its initial association with Linus. Which 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).

simias 7y ago

I'm reminded of that article I read on HN a few months ago about how "you're not Google/Amazon/Facebook" and you probably shouldn't base your technical choices on what these companies are doing because chances are that you have a massively different usage profile and very different priorities. Still, everybody wants to be like the big guys (dress for the job you want, not the one you have) so you still often seen small-ish websites using a ridiculously overpowered and over-architectured backend. 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.

philpem 7y ago
There are similar patterns in other industries. Manufacturing tends to fetishise the automotive industry -- so an absolute mountain of changes come from "well Toyota's doing it" or "well BMW is doing it". Of course, they're great solutions for building cars, but not so great when you're building TV remote controls. 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.
gilrain 7y ago
On the other hand, the software development version of the maxim "dress for the job you want, not the job you have" could easily be "use the tools the job you want uses, not just what you can get away with".

dragonsh 7y ago

Performance is not the reason GitHub chose git over mercurial. They chose git because their core developers understand internal architecture of git better. They were more proficient in Ruby and C than Python, so git was a natural choice for GitHub. 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.

jlebar 7y ago

> 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.

durin42 7y ago
Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.
- jlebar 7y ago
  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. :)
  - ezst 7y ago
    well, you just addressed this message to the current lead maintainer of Mercurial, who happens to be a fellow co-worker of yours ;)
  - mambru 7y ago
    Including durin42 himself ;)
pgt 7y ago
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. - [^1]: http://www.paulgraham.com/hundred.html http://www.paulgraham.com/hundred.html

rimliu 7y ago

I have no idea how good mercurial is now, but I think back in the days when git started to get ahead it was superior to mercurial in more than one way.

rsynnott 7y ago

> except performance 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.