4 ms·

Frankly, because of GitHub Late 2000s/Early 2010s there was greater variety in version control tooling. Distributed VCS was new. Mercurial promised to be the “

Frankly, because of GitHub Late 2000s/Early 2010s there was greater variety in version control tooling. Distributed VCS was new. Mercurial promised to be the “easy” version. Subversion was still heavily used and maintained. GitHub quickly established itself as THE place to share and collaborate code. To use it you had to learn git. Most people, still, to this day have a fairly shallow understanding of git and find themselves encountering lots of foot guns, lack of opinions, and UI inconsistencies. I’m not sure without GitHub, git would be as dominant.

astrange 5y ago
I have used git since the beginning, have worked on a very large mercurial project, and git was always better. Mercurial was very slow at the time and because it didn't have rebase, repo history got absolutely full up with merge commits. There was something called a patch queue that was like rebaseable pseudo-commits but it wasn't quite good enough. git didn't solve this problem hard enough (it still has merge commits and honestly I would like to see a model that doesn't have them at all, however that would work) but at least it was fast.
- williamstein 5y ago
  Here's my mathematician's perspective on this, having used CVS, Darcs, and Mercurial a lot before Git. One day, angry by the situation with Bitkeeper, Linus Torvalds thought to himself "Let's pretend that Sha1 hash collisions don't happen; what can we do?". The result that he deduced from this assumption was a distributed revision control system that was an order of magnitude more efficient than any of the competition, and this was absolutely critical to its success. And Linus probably just assumed the Sha1 problem could be sorted out later (like it was [1]). [1] https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...
- stevekemp 5y ago
  Similar story here, though I think we had the desire to move away from darcs too - because we were hitting the exponential-time problem with patch-replays. Darcs was a nice system, but with the unfixed(?) massive slowdown it just wasn't workable. We toyed with mercurial, but settled on git within a year or so.
slipframe 5y ago
In my recollection, github got popular fast because git was already the cool hype VCS. The kernel guys were the real trendsetters. It seemed like everybody and their mother was giving or attenting git presentations at work, college, LUGs, etc. Github rode that wave of hype at just the right time.

astrange 5y ago

I have used git since the beginning, have worked on a very large mercurial project, and git was always better. Mercurial was very slow at the time and because it didn't have rebase, repo history got absolutely full up with merge commits. There was something called a patch queue that was like rebaseable pseudo-commits but it wasn't quite good enough. git didn't solve this problem hard enough (it still has merge commits and honestly I would like to see a model that doesn't have them at all, however that would work) but at least it was fast.

williamstein 5y ago
Here's my mathematician's perspective on this, having used CVS, Darcs, and Mercurial a lot before Git. One day, angry by the situation with Bitkeeper, Linus Torvalds thought to himself "Let's pretend that Sha1 hash collisions don't happen; what can we do?". The result that he deduced from this assumption was a distributed revision control system that was an order of magnitude more efficient than any of the competition, and this was absolutely critical to its success. And Linus probably just assumed the Sha1 problem could be sorted out later (like it was [1]). [1] https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...
stevekemp 5y ago
Similar story here, though I think we had the desire to move away from darcs too - because we were hitting the exponential-time problem with patch-replays. Darcs was a nice system, but with the unfixed(?) massive slowdown it just wasn't workable. We toyed with mercurial, but settled on git within a year or so.

slipframe 5y ago

In my recollection, github got popular fast because git was already the cool hype VCS. The kernel guys were the real trendsetters. It seemed like everybody and their mother was giving or attenting git presentations at work, college, LUGs, etc. Github rode that wave of hype at just the right time.