5 ms·

Git succeeded because it was free, and then business models were able to be built up around the open-source ecosystem after a market evolved naturally. There is

Git succeeded because it was free, and then business models were able to be built up around the open-source ecosystem after a market evolved naturally. There is a need, but if you go into it trying to build a business from scratch, you're going to have a bad time.

TylerE 7y ago
Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel
- sdan 7y ago
  I'd argue it succeeded (at least more recently) because of the UX that companies like Github and Gitlab gave, not particularly linus or because it was free.
  - TylerE 7y ago
    If Linus hasn’t pushed it, it never would have caught on.
    - bryanrasmussen 7y ago
      Sure lots of good things would never catch on except an influential person in the field the good thing targets says: hey this is really useful for us! This gets lots of people to look at it. But those people still have to decide in the end of the day whether it is actually useful for them.
      - sdan 7y ago
        Reminds me of sports: Just because Steph Curry uses Under Armor doesn't mean everyone will too. I think obviously something created by Linus was deemed to be of great value, but what made Git as profound as it is today is: UX for the majority of people who are beginners, which was Github backed by millions of other developers.
  - babuskov 7y ago
    Github was made because people wanted to use Git really bad, but the UX wasn't there. Git was already successful at that point. Git succeeded because it was good. Github just made it more accessible.
- greggman3 7y ago
  Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don't use it. No idea why. Git people get how much freedom git branches give them, freedom that other vcs, include hg don't/didn't.
  - koonsolo 7y ago
    Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer. The other VCSes have an intuitive concept of branches, because they are in fact branches. I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.
    - barrkel 7y ago
      Git branches as labels into a DAG of edits maps exactly to what I think branches are. The difference between two branches is their respective edits from a common base. If you muck up a commit, you reset the pointer to the previous commit. If you muck that up, and accidentally reset too much, you can use your reflog to find out where you used to be on the DAG and reset the branch to that. The transparency of the mechanism enables the user to be more powerful while knowing fewer concepts in total. The power of the system comes from the composition of simple parts.
    - ynx 7y ago
      I must be an outlier, because it's always been the opposite for me. I started on Mercurial and didn't use Git for years. The moment I switched to Git everything made so much more sense to me. Mercurial seemed like it did magic and wouldn't explain it to you. There were multiple kinds of branches, there were revision numbers, octopus merges were impossible to understand, the whole thing tried to act immutable but effective workflows included history editing for squashing and merging and amending and cherry-picking, which is anything but. Partial commits were a little bit of a mystery to me, and shelves seemed to be their own separate thing. To me Git was simple in comparison. The working copy was the last state at the end of a long sequence of states. Patches were just the way you represented going from one state to another, rather than canonical, so you woujldn't resolve an octopus merge so much as you would get to your desired state and call it a day. Branches were labels to a particular state. Stashes were labels with an optimized workflow. Reflog was just a list of temporary-ish labels. New commits were built against the index, which you could add or remove to independently of file state. Branches were branches were branches, no matter where the repository was. Disconnecting from upstream was simply a matter of removing a remote. I know it doesn't match up with other people, but I simply have never been able to see Mercurial as an example of a good tool /despite starting on it/. It's always been easier to use git at any level of complexity I need it depending on the problem I'm solving, whether it's saving code or rescuing a totally botched interactive rebase, merge, etc.
- akvadrako 7y ago
  Before git came along monotone was looking like the best DVCS. But it had no chance to compete with Linus’ marketing power.
- stevekemp 7y ago
  DARCS would not have seen significant further growth, due to the merge-of-doom problem.
  - Tomte 7y ago
    It's been years since I have read about darcs. Did they fix that infinite time merge problem at some point?
    - stevekemp 7y ago
      Not entirely fixed by the look of things: Darcs 2 (introduced in 2008-04) reduces the name of scenarios that will trigger an exponential merge. Repositories created with Darcs 2 should have fewer exponential merges in practice. http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...
- tinco 7y ago
  99.99999% of projects are not the Linux kernel, so how could Git have succeeded because of Linus, other than Linus originating the genius design of it? The Ruby community jumped onto Git even though there was no Github, and Ruby itself didn't use Git. In my opinion it was because Git was the first tool that was superior to SVN in every way. The first time I used Git I swore I would never use SVN again. It was even popular back then to set up git+svn systems so you could work on your git repo, and push a branch to svn to satisfy your employer. People associate git with Github (and Gitlab), but it used to be very common to just set up a ssh server that people could push projects on to, my server still has a dozen or so projects on it that I haven't touched in a decade. Github spawned from the popularity of Git in the Ruby community, and the desire to make it a little more accessible to people that didn't want to have their own git servers.
  - wainstead 7y ago
    > so how could Git have succeeded because of Linus, other than Linus originating the genius design of it? Perhaps that is exactly the point. There was a fair amount of hype and press coverage over Git when it was first unveiled. And it was because Linus wrote it, and wrote it in an unexpectedly short time. And it was on the coattails of the whole Bitkeeper saga.
    - TylerE 7y ago
      Similar to how, say, Go and Rust became popular while nim and D have largely remained niche products PS: Hi, Steve!
      - wainstead 7y ago
        Hi Tyler! :)
- ComodoHacker 7y ago
  GP was probably meaning GitHub, not Git.
- tannerbrockwell 7y ago
  Git exists, because Bitkeeper were being Aholes. [1] A developer needed some metrics on the Bitkeeper repository that Linux used. Remember this is a proprietary and commercial product that granted a handful of licenses to the Linux community as a token of support. So when Andrew Tridgell reversed engineered the format that Bitkeeper used, they threatened to sue him under the DMCA. This caused a firestorm, some defended him, others defended Bitkeeper, and a lot of people said why the hell is Linus using proprietary software to manage an Open Source project?!?!! Linus waded in and said he'd think about it, I think was on a thursday or friday, and by the next week he had working python prototype of git. [2] The rest is history. Bitkeeper faded into irrelevance and git became the lingua franca for open source projects. Arguably its biggest strength was not revision control, but being designed in manner that many collaborators could seamlessly commit changes for merging. Obviously architected to fulfill the time consuming requirements of Linus Torvalds, it has stood a test of time. I'm writing this from memory, so if it disagrees with Wikipedia take it with a grain of salt. [1]: https://en.wikipedia.org/wiki/BitKeeper#Original_license_concerns https://en.wikipedia.org/wiki/BitKeeper#Original_license_con... [2]: https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History
  - specialist 7y ago
    Events like this, even in the small, keep me from outright dismissing "hero based" (whatever it's called) theories of explaining history. Coincidences, accidents, grudges, misunderstandings coupled with path dependencies.
    - TylerE 7y ago
      https://en.wikipedia.org/wiki/Great_man_theory https://en.wikipedia.org/wiki/Great_man_theory
waynesonfire 7y ago
being free is a huge plus; but more equally or even importantly, it's a better product.
- dagw 7y ago
  Was git really better than for example Mercury or Darcs for most 'normal' projects when it was released? I certainly don't remember it as such. It was certainly better for Linus and the specific workflow problems he had with kernel development, but I don't recall it being better overall at the time. What its release (and the very public BitKeeper spat leading up its release) did do was bring the idea of distributed VCS to the forefront.
  - jfkebwjsbx 7y ago
    Yes, it was way better. That is why people started using it outside the kernel. People forget how old Git is and think GitHub started it. Hg back in the day was quite limited and followed other VCS paradigm (which was enforced on you, by the way).

TylerE 7y ago

Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel

sdan 7y ago
I'd argue it succeeded (at least more recently) because of the UX that companies like Github and Gitlab gave, not particularly linus or because it was free.
- TylerE 7y ago
  If Linus hasn’t pushed it, it never would have caught on.
  - bryanrasmussen 7y ago
    Sure lots of good things would never catch on except an influential person in the field the good thing targets says: hey this is really useful for us! This gets lots of people to look at it. But those people still have to decide in the end of the day whether it is actually useful for them.
    - sdan 7y ago
      Reminds me of sports: Just because Steph Curry uses Under Armor doesn't mean everyone will too. I think obviously something created by Linus was deemed to be of great value, but what made Git as profound as it is today is: UX for the majority of people who are beginners, which was Github backed by millions of other developers.
- babuskov 7y ago
  Github was made because people wanted to use Git really bad, but the UX wasn't there. Git was already successful at that point. Git succeeded because it was good. Github just made it more accessible.
greggman3 7y ago
Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don't use it. No idea why. Git people get how much freedom git branches give them, freedom that other vcs, include hg don't/didn't.
- koonsolo 7y ago
  Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer. The other VCSes have an intuitive concept of branches, because they are in fact branches. I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.
  - barrkel 7y ago
    Git branches as labels into a DAG of edits maps exactly to what I think branches are. The difference between two branches is their respective edits from a common base. If you muck up a commit, you reset the pointer to the previous commit. If you muck that up, and accidentally reset too much, you can use your reflog to find out where you used to be on the DAG and reset the branch to that. The transparency of the mechanism enables the user to be more powerful while knowing fewer concepts in total. The power of the system comes from the composition of simple parts.
  - ynx 7y ago
    I must be an outlier, because it's always been the opposite for me. I started on Mercurial and didn't use Git for years. The moment I switched to Git everything made so much more sense to me. Mercurial seemed like it did magic and wouldn't explain it to you. There were multiple kinds of branches, there were revision numbers, octopus merges were impossible to understand, the whole thing tried to act immutable but effective workflows included history editing for squashing and merging and amending and cherry-picking, which is anything but. Partial commits were a little bit of a mystery to me, and shelves seemed to be their own separate thing. To me Git was simple in comparison. The working copy was the last state at the end of a long sequence of states. Patches were just the way you represented going from one state to another, rather than canonical, so you woujldn't resolve an octopus merge so much as you would get to your desired state and call it a day. Branches were labels to a particular state. Stashes were labels with an optimized workflow. Reflog was just a list of temporary-ish labels. New commits were built against the index, which you could add or remove to independently of file state. Branches were branches were branches, no matter where the repository was. Disconnecting from upstream was simply a matter of removing a remote. I know it doesn't match up with other people, but I simply have never been able to see Mercurial as an example of a good tool /despite starting on it/. It's always been easier to use git at any level of complexity I need it depending on the problem I'm solving, whether it's saving code or rescuing a totally botched interactive rebase, merge, etc.
akvadrako 7y ago
Before git came along monotone was looking like the best DVCS. But it had no chance to compete with Linus’ marketing power.
stevekemp 7y ago
DARCS would not have seen significant further growth, due to the merge-of-doom problem.
- Tomte 7y ago
  It's been years since I have read about darcs. Did they fix that infinite time merge problem at some point?
  - stevekemp 7y ago
    Not entirely fixed by the look of things: Darcs 2 (introduced in 2008-04) reduces the name of scenarios that will trigger an exponential merge. Repositories created with Darcs 2 should have fewer exponential merges in practice. http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...
tinco 7y ago
99.99999% of projects are not the Linux kernel, so how could Git have succeeded because of Linus, other than Linus originating the genius design of it? The Ruby community jumped onto Git even though there was no Github, and Ruby itself didn't use Git. In my opinion it was because Git was the first tool that was superior to SVN in every way. The first time I used Git I swore I would never use SVN again. It was even popular back then to set up git+svn systems so you could work on your git repo, and push a branch to svn to satisfy your employer. People associate git with Github (and Gitlab), but it used to be very common to just set up a ssh server that people could push projects on to, my server still has a dozen or so projects on it that I haven't touched in a decade. Github spawned from the popularity of Git in the Ruby community, and the desire to make it a little more accessible to people that didn't want to have their own git servers.
- wainstead 7y ago
  > so how could Git have succeeded because of Linus, other than Linus originating the genius design of it? Perhaps that is exactly the point. There was a fair amount of hype and press coverage over Git when it was first unveiled. And it was because Linus wrote it, and wrote it in an unexpectedly short time. And it was on the coattails of the whole Bitkeeper saga.
  - TylerE 7y ago
    Similar to how, say, Go and Rust became popular while nim and D have largely remained niche products PS: Hi, Steve!
    - wainstead 7y ago
      Hi Tyler! :)
ComodoHacker 7y ago
GP was probably meaning GitHub, not Git.
tannerbrockwell 7y ago
Git exists, because Bitkeeper were being Aholes. [1] A developer needed some metrics on the Bitkeeper repository that Linux used. Remember this is a proprietary and commercial product that granted a handful of licenses to the Linux community as a token of support. So when Andrew Tridgell reversed engineered the format that Bitkeeper used, they threatened to sue him under the DMCA. This caused a firestorm, some defended him, others defended Bitkeeper, and a lot of people said why the hell is Linus using proprietary software to manage an Open Source project?!?!! Linus waded in and said he'd think about it, I think was on a thursday or friday, and by the next week he had working python prototype of git. [2] The rest is history. Bitkeeper faded into irrelevance and git became the lingua franca for open source projects. Arguably its biggest strength was not revision control, but being designed in manner that many collaborators could seamlessly commit changes for merging. Obviously architected to fulfill the time consuming requirements of Linus Torvalds, it has stood a test of time. I'm writing this from memory, so if it disagrees with Wikipedia take it with a grain of salt. [1]: https://en.wikipedia.org/wiki/BitKeeper#Original_license_concerns https://en.wikipedia.org/wiki/BitKeeper#Original_license_con... [2]: https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History
- specialist 7y ago
  Events like this, even in the small, keep me from outright dismissing "hero based" (whatever it's called) theories of explaining history. Coincidences, accidents, grudges, misunderstandings coupled with path dependencies.
  - TylerE 7y ago
    https://en.wikipedia.org/wiki/Great_man_theory https://en.wikipedia.org/wiki/Great_man_theory

waynesonfire 7y ago

being free is a huge plus; but more equally or even importantly, it's a better product.

dagw 7y ago
Was git really better than for example Mercury or Darcs for most 'normal' projects when it was released? I certainly don't remember it as such. It was certainly better for Linus and the specific workflow problems he had with kernel development, but I don't recall it being better overall at the time. What its release (and the very public BitKeeper spat leading up its release) did do was bring the idea of distributed VCS to the forefront.
- jfkebwjsbx 7y ago
  Yes, it was way better. That is why people started using it outside the kernel. People forget how old Git is and think GitHub started it. Hg back in the day was quite limited and followed other VCS paradigm (which was enforced on you, by the way).