4 ms·

> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-

> marvel at how it ever became popular. It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then they ever were in those old systems - I've never spent more than an hour dealing with the results of git issues, but I've lost literal weeks to a single svn mishap. Why did git win over other dvcs systems? 2 main reasons I see: 1. Linux uses it - literally, that means its the "cool one" 2. Linux uses it - and that means the people developing it work similar to the kernel, they are willing to try a lot of different ways to acheive the task resulting in both some amazing cool stuff and a lot of cruft left hanging out for various compatability and "accidentally super important structurally" reasons.

jerf 4y ago
There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil. The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.) I expect to still be using git for many many years yet.
- silisili 4y ago
  Well said, but I humbly disagree that it has to be better in some way, just easier AND as technically sound. Unless that is by your definition better. Ease of use is probably one of the most important factors in real life in determining preferences for software. I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be a Git replacement, but a better frontend. Kind of how yay is to pacman. Or how most use something like Handbrake instead of ffmpeg. In a lot of ways, it reminds me of Python and Perl. Perl was definitely more powerful as a language, but Python felt like natural writing in pseudocode. Enthusiasts rightly point to the power of inbuilt regex, but like Git, few actually could harness it well enough to make that unreadability worth it.
  - jerf 4y ago
    "I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win." But we have that, and not only didn't it win, it shows no sign of winning. Mercurial isn't even growing in apparent mindshare. "Easier" and "technically sound" is by observation, not by a long line of strained theorizing, not enough. Theories must take this fact into account or be useless in explaining the real world.
evouga 4y ago
But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.
- KrisJordan 4y ago
  That your commits are made locally, in a clone of the entire repository, is decentralized. Your local respiratory accrues history as divergent (and unbeknownst) from upstream as you'd like it to. If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
- skybrian 4y ago
  It might not be more decentralized in practice, but it's easier to make and accept outside contributions. Before "pull requests" were a thing there was the "patch" command. I don't miss manually figuring out how many directory levels to strip to get a patch to apply, or figuring out what to do when patch says "applied 7 of 9 hunks" or whatever.
- sophacles 4y ago
  Everyone uses it the way it was intended. There's not really another option. Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. All of that is because you have a local copy of the repo and history, and can develop your way against your local repo then push the resulting changes upstream. The fact that this allows chaining of upstreams is not the main focus of "decentralized" wrt git and the other dvcs, that's just a side effect of the concept that appealed to Linus since it would better fit the kernel development model. From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
Fnoord 4y ago
> 1. Linux uses it - literally, that means its the "cool one" Linus Torvalds developed it after the spat with Bitkeeper, which was the main public proprietary dvcs. In a short time it became the most popular one. Which means all these people must be wrong otherwise. OpenBSD can use CVS cause they have a small, relatively static team.
lenkite 4y ago
git won in the greater world because of github.com. There was nothing at the time for mercurial OSS hosting.
- sophacles 4y ago
  Sure there was, it was called stash (and then that was bought by atlassian becoming bitbucket). You could host mercurial repos there until just a few years ago. And at that point, even the use of dvcs was in question, so you could use svn on google's forge, or sourceforge. Launchpad had bzr support too. It wasn't clear github was going to win until it was clear that git was going to win.
  - morelisp 4y ago
    Google Code also had hg support before it had git support, if I remember right. Certainly the SVN -> hg migration was easier than SVN -> git if you were using it.
    - ralgozino 4y ago
      And canonical's launchpad.net
      - morelisp 4y ago
        At the time I’m talking about that was a proprietary forge for bzr, Canonical’s unnecessary version of baz, which was the community fork of tla, which was the GNU experiment in DVCS with an even worse interface than git.
koonsolo 4y ago
I see you never worked with coworkers that were able to mess up a git system. And because git is so complex, it's pretty easy to mess up. Just let some junior developers to some rebases and squashes, and see what happens.

jerf 4y ago

There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil. The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.) I expect to still be using git for many many years yet.

silisili 4y ago
Well said, but I humbly disagree that it has to be better in some way, just easier AND as technically sound. Unless that is by your definition better. Ease of use is probably one of the most important factors in real life in determining preferences for software. I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be a Git replacement, but a better frontend. Kind of how yay is to pacman. Or how most use something like Handbrake instead of ffmpeg. In a lot of ways, it reminds me of Python and Perl. Perl was definitely more powerful as a language, but Python felt like natural writing in pseudocode. Enthusiasts rightly point to the power of inbuilt regex, but like Git, few actually could harness it well enough to make that unreadability worth it.
- jerf 4y ago
  "I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win." But we have that, and not only didn't it win, it shows no sign of winning. Mercurial isn't even growing in apparent mindshare. "Easier" and "technically sound" is by observation, not by a long line of strained theorizing, not enough. Theories must take this fact into account or be useless in explaining the real world.

evouga 4y ago

But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.

KrisJordan 4y ago
That your commits are made locally, in a clone of the entire repository, is decentralized. Your local respiratory accrues history as divergent (and unbeknownst) from upstream as you'd like it to. If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
skybrian 4y ago
It might not be more decentralized in practice, but it's easier to make and accept outside contributions. Before "pull requests" were a thing there was the "patch" command. I don't miss manually figuring out how many directory levels to strip to get a patch to apply, or figuring out what to do when patch says "applied 7 of 9 hunks" or whatever.
sophacles 4y ago
Everyone uses it the way it was intended. There's not really another option. Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. All of that is because you have a local copy of the repo and history, and can develop your way against your local repo then push the resulting changes upstream. The fact that this allows chaining of upstreams is not the main focus of "decentralized" wrt git and the other dvcs, that's just a side effect of the concept that appealed to Linus since it would better fit the kernel development model. From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.

Fnoord 4y ago

> 1. Linux uses it - literally, that means its the "cool one" Linus Torvalds developed it after the spat with Bitkeeper, which was the main public proprietary dvcs. In a short time it became the most popular one. Which means all these people must be wrong otherwise. OpenBSD can use CVS cause they have a small, relatively static team.

lenkite 4y ago

git won in the greater world because of github.com. There was nothing at the time for mercurial OSS hosting.

sophacles 4y ago
Sure there was, it was called stash (and then that was bought by atlassian becoming bitbucket). You could host mercurial repos there until just a few years ago. And at that point, even the use of dvcs was in question, so you could use svn on google's forge, or sourceforge. Launchpad had bzr support too. It wasn't clear github was going to win until it was clear that git was going to win.
- morelisp 4y ago
  Google Code also had hg support before it had git support, if I remember right. Certainly the SVN -> hg migration was easier than SVN -> git if you were using it.
  - ralgozino 4y ago
    And canonical's launchpad.net
    - morelisp 4y ago
      At the time I’m talking about that was a proprietary forge for bzr, Canonical’s unnecessary version of baz, which was the community fork of tla, which was the GNU experiment in DVCS with an even worse interface than git.

koonsolo 4y ago

I see you never worked with coworkers that were able to mess up a git system. And because git is so complex, it's pretty easy to mess up. Just let some junior developers to some rebases and squashes, and see what happens.