7 ms·

I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I undere

by 100k 11y ago

I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I underestimated how good it makes people feel to understand something incredibly complicated. I guess immutable history was a turn off for many people as well. This fake interview is pretty funny: "Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd." http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git/ http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

acdha 11y ago
The main thing I found was that Mercurial was only easier for the simplest introductory tasks, where Git has largely compensated with tons of documentation, tutorials and, later, improved command-line UI. Once you needed to do anything more complicated (e.g. working on against an upstream repo you don't have commit access to) you tended to quickly end up in documentation lacunae and semi-supported extensions which rotated in and out of favor depending on which year the guide you'd found was written. My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.
xiaomai 11y ago
That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff. tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.
- twic 11y ago
  You're right that Mercurial didn't have bookmarks until years after Git had branches. There were various things you could do to get a similar effect (eg having a branch with multiple heads), but none quite as good, and it took the Mercurial team a long time to come around to the idea. I have to disagree about the index, though. I use Git every day, and i'm still struck by how pointless the index and the idea of staging is. Ditto rebase. The routine use of rebase still seems completely wrongheaded to me. Mercurial's convention of preferring merges is better, and the last few years' developments around safe evolution of history really show rebase up as the misconceived hack it is. Mercurial got 'commit --amend' a long time ago, but even before that, it had 'rollback', which undoes the last commit, leaving the working tree untouched (that is, with the state it had in the commit), so you can make your fixes and commit again. I'd entertain the argument that Git won because it was better if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.
  - ngoldbaum 11y ago
    Nice comment. One gripe: "rollback" undoes the last transaction, which isn't necessarily the same as a commit. It's deprecated now for that reason.
  - zak_mc_kracken 11y ago
    > I use Git every day, and i'm still struck by how pointless the index and the idea of staging is. This is probably more a symptom of the fact that either your workflow doesn't require an index or you don't understand its value. Either way, the index is by far git's more popular and used feature, besides branches.
    - k__ 11y ago
      Care to elaborate? I use Git on a daily basis, but I never understood it. If I just want to commit a specific part of my changes, I just do it. It's nice to see which files are staged for a commit, but I also see them in the commit msg comments.
georgemcbay 11y ago
"I underestimated how good it makes people feel to understand something incredibly complicated" Or rather (in many cases) how good it makes people feel to use and tell other people they use something incredibly complicated, whether they actually understand it or not. I'd venture that a fairly large amount of the people who use git don't really understand it fully, they just understand some very small subset of what they picked up from whatever "best git flow" website or book they happened to read. Lest anyone think I'm being elitist here, I'll come right out and admit there's a ton of stuff in git I've never bothered to really understand. I'm okay with standard push/pull commits, stashing and rebasing, but I still kinda think of these things as sort of interpretations of concepts I'm used to from older non-DVCS systems, I don't "grok" git, not really -- never really bothered since I find source control systems incredibly useful but not inherently interesting (to me personally). All that said, I don't use git to show off, I use it because virtually everyone else does and there is a certain pragmatic benefit to going with the flow on something like that even if I think it is overkill for a lot of the projects I need a VCS for.
- ngoldbaum 11y ago
  Here's an interesting paper that largely confirms your supposition: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...
rdtsc 11y ago
It was performance that made git win initially. In benchmarks git did better in the past when there was still a great Cambrian explosion of DVCSs (Monotone, Bazaar, Hg, Git, Darcs,...) It is of course possible that performance follows a saddle like curve (or hump depending on how you look at it). For up to some size, git is faster. But at much larger ones a different algorithm wins out and hg could be end up being faster.
zak_mc_kracken 11y ago
> I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. What we've learned is that these two things are actually liabilities. git is a good example that the syntax of the command line is of no consequence. git's CLI is notoriously horrendous and bizarre, yet it didn't stop its adoption. And this is a problem that's easily worked around by creating tools (graphical ones and also porcelaines) around it. The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up. Strangely enough even git's initial hostility to running on Windows didn't stop its adoption. git's features and modeling of source control system is so powerful and flexible that git became successful in spite of all these other aspects. Frankly, I think it's silly to use any other source control these days: embrace git and get used to it because it's going to be around for a while.
- lake99 11y ago
  > The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up. This wasn't the case at all. In their early years, some operations were faster on git, and others, faster on Mercurial[1]. I don't remember any recent benchmarks, but early last year, there were reports of Facebook making Mercurial faster [2]. > Frankly, I think it's silly to use any other source control these days You might get that impression if your work is centered around github, but I have friends who use enterprise-specific extensions on Mercurial that structure their workflow. [1] http://draketo.de/proj/hg-vs-git-server/test-results.html http://draketo.de/proj/hg-vs-git-server/test-results.html [2] http://www.infoq.com/news/2014/01/facebook-scaling-hg http://www.infoq.com/news/2014/01/facebook-scaling-hg
  - zak_mc_kracken 11y ago
    You're not really disputing what I said: Mercurial is much, much slower than Git. Facebook forked it and managed to make it faster but they never released their fork so nobody can actually use it. The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.
mpdehaan2 11y ago
The friendliness in the mercurial CLI ceased to be an advantage just a few years after git came out, IMHO. git error messages got better. I had to re-use mercurial after leaving it for git at one workplace, and I was cringing most of the time. The main problem is that mercurial never got real branches, which is git's wheelhouse, forcing gross things like the "forest" extension (which I believe is now unmaintained). Maybe it's gotten better since then, but this was about 3-4 years ago. The way I see it, git has all the powertools you'd need, and you don't have to use them most of the time, where as mercurial feels generally stripped down to be "easy", and when you want to do the hard things, it's not so good at it. One of those examples might be something like grafting a repo into another repo at a arbitrary root, or some of the tricks you can do to edit previous commits (say if you mispelled your username all the way down). My main point of switching originally was when I believe it mixed up a lot of commits in a merge and lost some changes. I also recall hearing about a patch for predictable ordering in diff output being rejected. git's really gotten TONS better -- way back, I would say mercurial was easier to use, and git really excels at branch based workflows which at this point I can't live without. Of course, a worse thing from having to work at a mercurial shop after loving git is having to work at a SVN shop :)
andrewflnr 11y ago
This attitude of "oh, the only reason it's popular is because people want to feel superior for learning something hard" is poisonous to productive discussion. If you're going to be cynical about it, at least favor the "OMG Linus Torvalds maed it" explanation over the one that requires active assholery on the part of Git users. Better yet, try assuming that most people are making a reasonable effort to be rational based on their limited knowledge. But what you did right there, please don't do that.
- mistermann 11y ago
  Anecdotal of course, but in my limited experience, I've seen plenty of superiority complexes and generally assholery, but no Linus fanboyism. I don't like it, but to me it seems like a perfectly unsurprising aspect of the software industry. Your idea (my interpretation) that the industry mostly consists of people having productive discussions seems more off base. Yes, that's the way it should be, and usually is on HN and similar forums, but out in the larger real world, arrogance, superiority, etc are the order of the day.
  - andrewflnr 11y ago
    Yes, I know the real world sucks. In light of that, let's try not to actively make it worse. Applying Hanlon's Razor aggressively is the easiest thing we can do. And don't forget the selection bias from the fact that jerks are more likely to make themselves noticed than rational people.
  - woah 11y ago
    If I'm reading this thread correctly, hg doesn't even have a staging area! And you've got to come up with some far-fetched conspiracy theory?
- reality_czech 11y ago
  Or you could mention the elephant in the room, the fact that git is orders of magnitude faster than mercurial when your project grows beyond the "small" size. Mercurial would be unusable on something like the Linux kernel, and uncomfortably slow on a lot of other projects. And big projects tend to have more developer mindshare-- funny how that works...

by 100k 11y ago

acdha 11y ago

The main thing I found was that Mercurial was only easier for the simplest introductory tasks, where Git has largely compensated with tons of documentation, tutorials and, later, improved command-line UI. Once you needed to do anything more complicated (e.g. working on against an upstream repo you don't have commit access to) you tended to quickly end up in documentation lacunae and semi-supported extensions which rotated in and out of favor depending on which year the guide you'd found was written. My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.

xiaomai 11y ago

That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff. tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.

twic 11y ago
You're right that Mercurial didn't have bookmarks until years after Git had branches. There were various things you could do to get a similar effect (eg having a branch with multiple heads), but none quite as good, and it took the Mercurial team a long time to come around to the idea. I have to disagree about the index, though. I use Git every day, and i'm still struck by how pointless the index and the idea of staging is. Ditto rebase. The routine use of rebase still seems completely wrongheaded to me. Mercurial's convention of preferring merges is better, and the last few years' developments around safe evolution of history really show rebase up as the misconceived hack it is. Mercurial got 'commit --amend' a long time ago, but even before that, it had 'rollback', which undoes the last commit, leaving the working tree untouched (that is, with the state it had in the commit), so you can make your fixes and commit again. I'd entertain the argument that Git won because it was better if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.
- ngoldbaum 11y ago
  Nice comment. One gripe: "rollback" undoes the last transaction, which isn't necessarily the same as a commit. It's deprecated now for that reason.
- zak_mc_kracken 11y ago
  > I use Git every day, and i'm still struck by how pointless the index and the idea of staging is. This is probably more a symptom of the fact that either your workflow doesn't require an index or you don't understand its value. Either way, the index is by far git's more popular and used feature, besides branches.
  - k__ 11y ago
    Care to elaborate? I use Git on a daily basis, but I never understood it. If I just want to commit a specific part of my changes, I just do it. It's nice to see which files are staged for a commit, but I also see them in the commit msg comments.

georgemcbay 11y ago

"I underestimated how good it makes people feel to understand something incredibly complicated" Or rather (in many cases) how good it makes people feel to use and tell other people they use something incredibly complicated, whether they actually understand it or not. I'd venture that a fairly large amount of the people who use git don't really understand it fully, they just understand some very small subset of what they picked up from whatever "best git flow" website or book they happened to read. Lest anyone think I'm being elitist here, I'll come right out and admit there's a ton of stuff in git I've never bothered to really understand. I'm okay with standard push/pull commits, stashing and rebasing, but I still kinda think of these things as sort of interpretations of concepts I'm used to from older non-DVCS systems, I don't "grok" git, not really -- never really bothered since I find source control systems incredibly useful but not inherently interesting (to me personally). All that said, I don't use git to show off, I use it because virtually everyone else does and there is a certain pragmatic benefit to going with the flow on something like that even if I think it is overkill for a lot of the projects I need a VCS for.

ngoldbaum 11y ago
Here's an interesting paper that largely confirms your supposition: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf https://static.googleusercontent.com/media/research.google.c...

rdtsc 11y ago

It was performance that made git win initially. In benchmarks git did better in the past when there was still a great Cambrian explosion of DVCSs (Monotone, Bazaar, Hg, Git, Darcs,...) It is of course possible that performance follows a saddle like curve (or hump depending on how you look at it). For up to some size, git is faster. But at much larger ones a different algorithm wins out and hg could be end up being faster.

zak_mc_kracken 11y ago

> I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. What we've learned is that these two things are actually liabilities. git is a good example that the syntax of the command line is of no consequence. git's CLI is notoriously horrendous and bizarre, yet it didn't stop its adoption. And this is a problem that's easily worked around by creating tools (graphical ones and also porcelaines) around it. The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up. Strangely enough even git's initial hostility to running on Windows didn't stop its adoption. git's features and modeling of source control system is so powerful and flexible that git became successful in spite of all these other aspects. Frankly, I think it's silly to use any other source control these days: embrace git and get used to it because it's going to be around for a while.

lake99 11y ago
> The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up. This wasn't the case at all. In their early years, some operations were faster on git, and others, faster on Mercurial[1]. I don't remember any recent benchmarks, but early last year, there were reports of Facebook making Mercurial faster [2]. > Frankly, I think it's silly to use any other source control these days You might get that impression if your work is centered around github, but I have friends who use enterprise-specific extensions on Mercurial that structure their workflow. [1] http://draketo.de/proj/hg-vs-git-server/test-results.html http://draketo.de/proj/hg-vs-git-server/test-results.html [2] http://www.infoq.com/news/2014/01/facebook-scaling-hg http://www.infoq.com/news/2014/01/facebook-scaling-hg
- zak_mc_kracken 11y ago
  You're not really disputing what I said: Mercurial is much, much slower than Git. Facebook forked it and managed to make it faster but they never released their fork so nobody can actually use it. The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.

mpdehaan2 11y ago

The friendliness in the mercurial CLI ceased to be an advantage just a few years after git came out, IMHO. git error messages got better. I had to re-use mercurial after leaving it for git at one workplace, and I was cringing most of the time. The main problem is that mercurial never got real branches, which is git's wheelhouse, forcing gross things like the "forest" extension (which I believe is now unmaintained). Maybe it's gotten better since then, but this was about 3-4 years ago. The way I see it, git has all the powertools you'd need, and you don't have to use them most of the time, where as mercurial feels generally stripped down to be "easy", and when you want to do the hard things, it's not so good at it. One of those examples might be something like grafting a repo into another repo at a arbitrary root, or some of the tricks you can do to edit previous commits (say if you mispelled your username all the way down). My main point of switching originally was when I believe it mixed up a lot of commits in a merge and lost some changes. I also recall hearing about a patch for predictable ordering in diff output being rejected. git's really gotten TONS better -- way back, I would say mercurial was easier to use, and git really excels at branch based workflows which at this point I can't live without. Of course, a worse thing from having to work at a mercurial shop after loving git is having to work at a SVN shop :)

andrewflnr 11y ago

This attitude of "oh, the only reason it's popular is because people want to feel superior for learning something hard" is poisonous to productive discussion. If you're going to be cynical about it, at least favor the "OMG Linus Torvalds maed it" explanation over the one that requires active assholery on the part of Git users. Better yet, try assuming that most people are making a reasonable effort to be rational based on their limited knowledge. But what you did right there, please don't do that.

mistermann 11y ago
Anecdotal of course, but in my limited experience, I've seen plenty of superiority complexes and generally assholery, but no Linus fanboyism. I don't like it, but to me it seems like a perfectly unsurprising aspect of the software industry. Your idea (my interpretation) that the industry mostly consists of people having productive discussions seems more off base. Yes, that's the way it should be, and usually is on HN and similar forums, but out in the larger real world, arrogance, superiority, etc are the order of the day.
- andrewflnr 11y ago
  Yes, I know the real world sucks. In light of that, let's try not to actively make it worse. Applying Hanlon's Razor aggressively is the easiest thing we can do. And don't forget the selection bias from the fact that jerks are more likely to make themselves noticed than rational people.
- woah 11y ago
  If I'm reading this thread correctly, hg doesn't even have a staging area! And you've got to come up with some far-fetched conspiracy theory?
reality_czech 11y ago
Or you could mention the elephant in the room, the fact that git is orders of magnitude faster than mercurial when your project grows beyond the "small" size. Mercurial would be unusable on something like the Linux kernel, and uncomfortably slow on a lot of other projects. And big projects tend to have more developer mindshare-- funny how that works...