5 ms·

Git: Bram Cohen vs Linus Torvalds

118 points by Xichekolas 18y ago

SwellJoe 18y ago
Linus' strength, I think, and this article is pointing out one particular instance of that strength, is in spotting the right problem...not in any particular brilliance in solving the problem (though he's pretty good at solving the problems, as well). I suspect Bram is as talented a developer as Linus, but in chasing down elegant solutions to esoteric problems while Linus spotted and solved the problems that most effect developers, Codeville has missed the boat. I suspect the revision control wars are pretty much over for the next few years, and git won by a large margin. That, in and of itself, is an interesting indication of Linus' genius...he built something that had dozens of competitors, some with major backing like Canonical's bzr, and within a couple of months it was apparent to just about everyone that git had the mindshare for next generation revision control. His solution was ugly, just some C and Perl scripts thrown together in a short period of time, but it solved the right problems at the right time.
- axod 18y ago
  Has git really won? It'd be interesting to see some real stats, also how far has it actually penetrated businesses etc.
  - likpok 18y ago
    From what I hear, git has won the technical challenge. That is, I do not hear anyone claiming that their VCS is better than git in any significant manner.
  - sho 18y ago
    I don't have any stats, but my Zeitgeist-ometer tells me that it certainly has, and by a wide margin. It would be very difficult to get reliable numbers but I would be surprised if GitHub alone doesn't have more projects on it than every other DVCS put together. Projects are actually migrating to it from svn, which is a powerful vote of confidence. Perl just did a few weeks ago. Yep, Git's won all right.
  - kragen 18y ago
    Well, it's certainly beaten the crap out of Codeville, Monotone, OpenCM, darcs, ArX, and the other various decentralized source control systems that have been presented at CodeCon (Bram's conference), including the one Bram wrote. I decided that Git had won about a year ago, so I switched to it (from CVS and darcs). Mercurial still looked like it might be a reasonable competitor at the time, and it certainly isn't going to disappear, but Git is definitely in the lead at this point.
    - axod 18y ago
      Certainly seems to have won the popularity contest, but that doesn't map to what is actually in use across the board - businesses, universities, open source, etc etc
      - nostrademons 18y ago
        It's won the mindshare of the people who typically start new projects: hackers, entrepreneurs, independent developers, freelancers. Existing projects rarely switch VCses, because it's such a pain to move everything over. So new ones gain market share by being the choice of new projects, which then gradually displace old projects in the marketplace. This takes basically forever: a lot of people are still using CVS. But git's won the battle for folks creating new codebases, so it's basically inevitable at this point that people will eventually migrate over to it.
        SwellJoe 18y ago
        Existing projects rarely switch VCses, because it's such a pain to move everything over. git trounces the competition on this single point, actually, and it could even be one part of the explanation for why git has won so soundly. The tools for converting from another VCS to git are dramatically better than any other DVCS that I'm aware of.
        nuclear_eclipse 18y ago
        That's a very good point. For the MantisBT project, we were interested in moving from SVN (after our initial move away from CVS) to a DVCS, and Git's excellent `git-svn` layer allowed us to experiment with using Git while still working on a day-to-day basis within our central SVN repository. It was an extremely useful method of evaluating a new source control tool, with reliable usage in pulling from and committing directly to the underlying SVN repository.
  - etal 18y ago
    Gnome ran a survey to see what contributors are using and what they like. The most thorough crunching of that data is here (scroll down a bit): http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/ http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-r... Another analysis of the same data is here, with even more striking visuals: http://wingolog.org/archives/2009/01/06/git-and-bzr http://wingolog.org/archives/2009/01/06/git-and-bzr It looks like git does indeed have the win.
  - SwellJoe 18y ago
    Has git really won? Can you name any other DVCS that you believe will outpace, or even catch up with, git in the next couple of years for userbase and mindshare?
  - tjogin 18y ago
    Git has won insofar as it is superior. The pace at which ignorant and late businesses catch on to this fact is of only tangential interest.
- dkarl 18y ago
  Absolutely. Linus recognized three things: 1. There is no good solution to merging (the only theoretically interesting aspect of source control.) 2. Of all the "bad" solutions to merging, the best one is to handle whatever cases you can and delegate all other cases to humans. 3. There was a lot to be gained from applying serious brainpower to the supposedly easy, supposedly theoretically boring aspects of version control. Linus has a brilliant technical mind, but unlike most brilliant people, he does not have tunnel vision that steers him towards problems that are already framed as "interesting" problems in an existing theoretical framework.
- kragen 18y ago
  Also, as has been reported in the press, the two developers of Codeville have spent some years not on speaking terms. And Linus knows how to foster a community of developers, and in fact already had one attached to him; Bram has not been observed to have this skill.
  - pageman 18y ago
    I think part of the reason might be is that Bram has supposedly self-diagnosed himself to having Asperger's Syndrome http://en.wikipedia.org/wiki/Bram_Cohen http://en.wikipedia.org/wiki/Bram_Cohen
    - kragen 18y ago
      One might nitpick and say that the relevant issue is whether he would be correct to do so, rather than whether he has done so. I am fairly sure he is correct.
swillden 18y ago
I think an Bram errs when he thinks that his experience in studying and experimenting with merge algorithms gives him deeper insight than the apparent newcomer to the field, Linus. What he's missing is that Linus has spent a large part of nearly two decades doing merges using a variety of inadequate tools which no doubt frequently forced him to hand-edit many thousands of patches in order to get successful merges. When Linus sat down to start his two-week project, he brought with him an incredibly rich base of experience with real-world merging of changes in a significant, complex codebase with large numbers of contributors. Also, he's an insightful guy. So while he may not have spent as much time in formal study of the esoteric intricacies, Linus had great insight into the day-to-day issues that merge-heavy development processes create, and how to solve them.
- dasil003 18y ago
  And more importantly he had seen so many thousands of conflicts that he realized the futility of a smart algorithm significantly reducing the pain. Think about it, a bad automated merge probably causes as much pain as is alleviated by 10 trivial merge resolutions.
  - aaronblohowiak 18y ago
    ... it also spits out very good explanations of what failed in the more complex merges, which saves you time. I love good error messages.
    - windsurfer 18y ago
      I do too, and as someone who has just started using Git... the error messages need some help. Luckily, it's open source, so I decided to take a look and see if I could improve them... unfortunately, they are hard-coded into the source, and not in some central location, making it very difficult to change.
  - lacker 18y ago
    I completely agree but you are not extreme enough - I would rather have 100 trivial manual merge resolutions than 1 bad automated merge. You might not even notice your bad automated merge and that gets to be serious badness.
nihilocrat 18y ago
I don't have much appetite for commentary on internet pissing matches. However, I don't want to sound like a complete curmudgeon! I think the "What Git does right" section is a nice read.
- Xichekolas 18y ago
  Well I linked this page instead of the original mailing list thread for two reasons: 1. He strips all the 'pissing' out of the matches... the underlying argument got kind of bitter. 2. His commentary summarizes the important parts on one page, and points out the fundamental difference in their viewpoints. Namely, Bram was focused on making the best merge tool, whereas Linus was focused on making something so merging ends up being a small part of the larger goal of versioning the underlying content instead of just files.
gcheong 18y ago
You might be interested in this talk Torvalds gave at Google where he talks about how Git came about: http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8
staunch 18y ago
Cohen is now to revision control what Tanenbaum is to free Unix clones.
adambyrtek 18y ago
There is a lovely quote in the linked post: "Maybe someday somebody will do a PhD thesis on that topic and we'll add it, but until then we're sticking with the basic functionality." I guess not much innovation would happen if everybody waited for a PhD thesis to be published on a given subject instead of experimenting with their own ideas.
tjogin 18y ago
This mirrors my own realization; With Linux, Linus showed me he is an extremely good programmer. With Git, Linus showed me that he is a true genius.

118 points by Xichekolas 18y ago

Linus' strength, I think, and this article is pointing out one particular instance of that strength, is in spotting the right problem...not in any particular brilliance in solving the problem (though he's pretty good at solving the problems, as well). I suspect Bram is as talented a developer as Linus, but in chasing down elegant solutions to esoteric problems while Linus spotted and solved the problems that most effect developers, Codeville has missed the boat. I suspect the revision control wars are pretty much over for the next few years, and git won by a large margin. That, in and of itself, is an interesting indication of Linus' genius...he built something that had dozens of competitors, some with major backing like Canonical's bzr, and within a couple of months it was apparent to just about everyone that git had the mindshare for next generation revision control. His solution was ugly, just some C and Perl scripts thrown together in a short period of time, but it solved the right problems at the right time.

axod 18y ago
Has git really won? It'd be interesting to see some real stats, also how far has it actually penetrated businesses etc.
- likpok 18y ago
  From what I hear, git has won the technical challenge. That is, I do not hear anyone claiming that their VCS is better than git in any significant manner.
- sho 18y ago
  I don't have any stats, but my Zeitgeist-ometer tells me that it certainly has, and by a wide margin. It would be very difficult to get reliable numbers but I would be surprised if GitHub alone doesn't have more projects on it than every other DVCS put together. Projects are actually migrating to it from svn, which is a powerful vote of confidence. Perl just did a few weeks ago. Yep, Git's won all right.
- kragen 18y ago
  Well, it's certainly beaten the crap out of Codeville, Monotone, OpenCM, darcs, ArX, and the other various decentralized source control systems that have been presented at CodeCon (Bram's conference), including the one Bram wrote. I decided that Git had won about a year ago, so I switched to it (from CVS and darcs). Mercurial still looked like it might be a reasonable competitor at the time, and it certainly isn't going to disappear, but Git is definitely in the lead at this point.
  - axod 18y ago
    Certainly seems to have won the popularity contest, but that doesn't map to what is actually in use across the board - businesses, universities, open source, etc etc
    - nostrademons 18y ago
      It's won the mindshare of the people who typically start new projects: hackers, entrepreneurs, independent developers, freelancers. Existing projects rarely switch VCses, because it's such a pain to move everything over. So new ones gain market share by being the choice of new projects, which then gradually displace old projects in the marketplace. This takes basically forever: a lot of people are still using CVS. But git's won the battle for folks creating new codebases, so it's basically inevitable at this point that people will eventually migrate over to it.
      - SwellJoe 18y ago
        Existing projects rarely switch VCses, because it's such a pain to move everything over. git trounces the competition on this single point, actually, and it could even be one part of the explanation for why git has won so soundly. The tools for converting from another VCS to git are dramatically better than any other DVCS that I'm aware of.
        nuclear_eclipse 18y ago
        That's a very good point. For the MantisBT project, we were interested in moving from SVN (after our initial move away from CVS) to a DVCS, and Git's excellent `git-svn` layer allowed us to experiment with using Git while still working on a day-to-day basis within our central SVN repository. It was an extremely useful method of evaluating a new source control tool, with reliable usage in pulling from and committing directly to the underlying SVN repository.
- etal 18y ago
  Gnome ran a survey to see what contributors are using and what they like. The most thorough crunching of that data is here (scroll down a bit): http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/ http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-r... Another analysis of the same data is here, with even more striking visuals: http://wingolog.org/archives/2009/01/06/git-and-bzr http://wingolog.org/archives/2009/01/06/git-and-bzr It looks like git does indeed have the win.
- SwellJoe 18y ago
  Has git really won? Can you name any other DVCS that you believe will outpace, or even catch up with, git in the next couple of years for userbase and mindshare?
- tjogin 18y ago
  Git has won insofar as it is superior. The pace at which ignorant and late businesses catch on to this fact is of only tangential interest.
dkarl 18y ago
Absolutely. Linus recognized three things: 1. There is no good solution to merging (the only theoretically interesting aspect of source control.) 2. Of all the "bad" solutions to merging, the best one is to handle whatever cases you can and delegate all other cases to humans. 3. There was a lot to be gained from applying serious brainpower to the supposedly easy, supposedly theoretically boring aspects of version control. Linus has a brilliant technical mind, but unlike most brilliant people, he does not have tunnel vision that steers him towards problems that are already framed as "interesting" problems in an existing theoretical framework.
kragen 18y ago
Also, as has been reported in the press, the two developers of Codeville have spent some years not on speaking terms. And Linus knows how to foster a community of developers, and in fact already had one attached to him; Bram has not been observed to have this skill.
- pageman 18y ago
  I think part of the reason might be is that Bram has supposedly self-diagnosed himself to having Asperger's Syndrome http://en.wikipedia.org/wiki/Bram_Cohen http://en.wikipedia.org/wiki/Bram_Cohen
  - kragen 18y ago
    One might nitpick and say that the relevant issue is whether he would be correct to do so, rather than whether he has done so. I am fairly sure he is correct.

swillden 18y ago

I think an Bram errs when he thinks that his experience in studying and experimenting with merge algorithms gives him deeper insight than the apparent newcomer to the field, Linus. What he's missing is that Linus has spent a large part of nearly two decades doing merges using a variety of inadequate tools which no doubt frequently forced him to hand-edit many thousands of patches in order to get successful merges. When Linus sat down to start his two-week project, he brought with him an incredibly rich base of experience with real-world merging of changes in a significant, complex codebase with large numbers of contributors. Also, he's an insightful guy. So while he may not have spent as much time in formal study of the esoteric intricacies, Linus had great insight into the day-to-day issues that merge-heavy development processes create, and how to solve them.

dasil003 18y ago
And more importantly he had seen so many thousands of conflicts that he realized the futility of a smart algorithm significantly reducing the pain. Think about it, a bad automated merge probably causes as much pain as is alleviated by 10 trivial merge resolutions.
- aaronblohowiak 18y ago
  ... it also spits out very good explanations of what failed in the more complex merges, which saves you time. I love good error messages.
  - windsurfer 18y ago
    I do too, and as someone who has just started using Git... the error messages need some help. Luckily, it's open source, so I decided to take a look and see if I could improve them... unfortunately, they are hard-coded into the source, and not in some central location, making it very difficult to change.
- lacker 18y ago
  I completely agree but you are not extreme enough - I would rather have 100 trivial manual merge resolutions than 1 bad automated merge. You might not even notice your bad automated merge and that gets to be serious badness.

nihilocrat 18y ago

I don't have much appetite for commentary on internet pissing matches. However, I don't want to sound like a complete curmudgeon! I think the "What Git does right" section is a nice read.

Xichekolas 18y ago
Well I linked this page instead of the original mailing list thread for two reasons: 1. He strips all the 'pissing' out of the matches... the underlying argument got kind of bitter. 2. His commentary summarizes the important parts on one page, and points out the fundamental difference in their viewpoints. Namely, Bram was focused on making the best merge tool, whereas Linus was focused on making something so merging ends up being a small part of the larger goal of versioning the underlying content instead of just files.

gcheong 18y ago

You might be interested in this talk Torvalds gave at Google where he talks about how Git came about: http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8

staunch 18y ago

Cohen is now to revision control what Tanenbaum is to free Unix clones.

adambyrtek 18y ago

There is a lovely quote in the linked post: "Maybe someday somebody will do a PhD thesis on that topic and we'll add it, but until then we're sticking with the basic functionality." I guess not much innovation would happen if everybody waited for a PhD thesis to be published on a given subject instead of experimenting with their own ideas.

tjogin 18y ago

This mirrors my own realization; With Linux, Linus showed me he is an extremely good programmer. With Git, Linus showed me that he is a true genius.