3 ms·

1. Network effects 2. Timing The world was ready for a replacement for SVN just at the moment when git hit the scene, and it was just good enough to take over

by Lazare 5y ago

1. Network effects 2. Timing The world was ready for a replacement for SVN just at the moment when git hit the scene, and it was just good enough to take over. Mercurial dates to the same era and was just about as good (arguably better), and could easily have won out instead, but tiny difference in initial adoption snowballed, and so git won and mercurial lost (as did Bazaar, Fossil, etc.) And while git is hardly perfect, a git killer needs to not just be 15% better, but hugely better; a big enough gap to trigger another industry wide shift. "It's like git, but we made the UI 15% nicer" seems like a good sales pitch, but it's not going to motivate people into becoming evangelists for their teams to adopt it, and that's what you need. (Git, for all its flaws, was enough better than SVN that people absolutely fought to change over.)

trhway 5y ago
>The world was ready for a replacement for SVN the world was ready for SVN replacement before the SVN :) SVN was a band-aid, a stop-gap multi-repo measure on top of CVS. The word wanted multi-repo with good sync between repos and with local history, which is basically a repo too. Mercurial and Git were 2 of those new gen version controls. >Mercurial dates to the same era and was just about as good (arguably better) no. In particular a killer, in the sense of adoption killer, was that opinionated absence of partial transactions in Mercurial. Also branching in Mercurial wasn't that easy/cheap/natural like in Git. >tiny difference in initial adoption snowballed not really. If anything, BigCo-s were choosing mercurial over git because mercurial was more like rational/etc and appealed to those tech leads/architects/managers there. Didn't help. The git was built for developers by developers (basically Linus, forced to move on from BitKeeper, re-implemented and improved upon BitKeeper in application to his task in hand - ie. large distributed development). Git wasn't an obstacle/hurdle, it was the tool multiplying your productivity. (i worked on some pre-git source control tool in well pre-git times, and i remember us discussing, even filing some patents on and building some features in our tool similar to what later git brought to the wide world)
riquito 5y ago
Mercurial was slower on every possible metric (albeit faster than the competition). Git felt like magic. git-svn probably helped out too, it made the transition from svn way smoother
genmud 5y ago
3. Branding I think one of the big things as well that propelled Git to win was the fact that it was "made by the guy who does linux", easy to remember and later GitHub/GitLab reinforced that branding. I was a huge mercurial fan, I was also a pretty heavy user of BitBucket (which at the time was only mercurial). It was always a mouthful to talk about mercurial or bazaar. Once people started jumping from google code in 2010-2012 to GitHub, the writing was on the wall for hg.
- wink 5y ago
  We may be both tainted by personal experience here, just from different sides. Back when the race was still close I actually used git and mercurial for about the same amount of time (main work stuff was still svn) and I found git to be superior in every way. That's why I'm cautious to attribute anything I noticed to either one winning. mercurial wasn't bad at all, but it was just a tiny bit worse than git for everything I tried.
juancn 5y ago
Mercurial was good but awfully slow, particularly on medium to large projects. The lack of APIs didn’t help either.

by Lazare 5y ago

trhway 5y ago

>The world was ready for a replacement for SVN the world was ready for SVN replacement before the SVN :) SVN was a band-aid, a stop-gap multi-repo measure on top of CVS. The word wanted multi-repo with good sync between repos and with local history, which is basically a repo too. Mercurial and Git were 2 of those new gen version controls. >Mercurial dates to the same era and was just about as good (arguably better) no. In particular a killer, in the sense of adoption killer, was that opinionated absence of partial transactions in Mercurial. Also branching in Mercurial wasn't that easy/cheap/natural like in Git. >tiny difference in initial adoption snowballed not really. If anything, BigCo-s were choosing mercurial over git because mercurial was more like rational/etc and appealed to those tech leads/architects/managers there. Didn't help. The git was built for developers by developers (basically Linus, forced to move on from BitKeeper, re-implemented and improved upon BitKeeper in application to his task in hand - ie. large distributed development). Git wasn't an obstacle/hurdle, it was the tool multiplying your productivity. (i worked on some pre-git source control tool in well pre-git times, and i remember us discussing, even filing some patents on and building some features in our tool similar to what later git brought to the wide world)

riquito 5y ago

Mercurial was slower on every possible metric (albeit faster than the competition). Git felt like magic. git-svn probably helped out too, it made the transition from svn way smoother

genmud 5y ago

3. Branding I think one of the big things as well that propelled Git to win was the fact that it was "made by the guy who does linux", easy to remember and later GitHub/GitLab reinforced that branding. I was a huge mercurial fan, I was also a pretty heavy user of BitBucket (which at the time was only mercurial). It was always a mouthful to talk about mercurial or bazaar. Once people started jumping from google code in 2010-2012 to GitHub, the writing was on the wall for hg.

wink 5y ago
We may be both tainted by personal experience here, just from different sides. Back when the race was still close I actually used git and mercurial for about the same amount of time (main work stuff was still svn) and I found git to be superior in every way. That's why I'm cautious to attribute anything I noticed to either one winning. mercurial wasn't bad at all, but it was just a tiny bit worse than git for everything I tried.

juancn 5y ago

Mercurial was good but awfully slow, particularly on medium to large projects. The lack of APIs didn’t help either.