
Git: Bram Cohen vs Linus Torvalds - Xichekolas
http://wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
======
swillden
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
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
... 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
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.

------
SwellJoe
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
Has git really won? It'd be interesting to see some real stats, also how far
has it actually penetrated businesses etc.

~~~
kragen
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
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
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
_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
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.

~~~
nostrademons
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.

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

------
gcheong
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>

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

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

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

