Git: Bram Cohen vs Linus Torvalds | Hacker News Reader

Git: Bram Cohen vs Linus Torvalds

wincent.com

118 pointsXichekolas31 comments

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.

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.

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.

... it also spits out very good explanations of what failed in the more complex merges, which saves you time. I love good error messages.

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.

You're still thinking like a developer (like Bram) by emphasizing the merging algorithm too much. It wasn't Linus's experience merging that helped him design the superior software. It was all the rest of his project-management experience, which helped him realize the role of merging within the broader system.

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.

Whatever the value of years of experience, it's foolish to disregard the cost of bias those years build, also.

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.

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.

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.

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

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.

Has git really won? It'd be interesting to see some real stats, also how far has it actually penetrated businesses etc.

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.

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

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.

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.

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.

It's also really nice that git can often coexist with an existing VCS in the same working directory structure, and then you just delete the .git directory when you're done.

I started using git this way - I had a svn project that I had to go offline with for about a week, so I setup a git repository so I wouldn't lose my work, and then just checked the final state in and deleted the .git directory afterwards. And I currently have to use Perforce at work, but I'll frequently setup a quick git repository to checkpoint large changelists while I'm working on them.

A lot of those have probably only recently moved from CVS to Subversion, it will take them a long time to move to git (or anything else).

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-r...

Another analysis of the same data is here, with even more striking visuals:

http://wingolog.org/archives/2009/01/06/git-and-bzr

It looks like git does indeed have the win.

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.

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.

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?

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.

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.

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

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

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.

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.

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.

Reply on news.ycombinator.com