
A look back: Bram Cohen vs Linus Torvalds (2007) - dkarapetyan
http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
======
kbenson
> But after closely studying Git I'm a little bit awestruck; Torvalds is a
> frickin' genius, a true visionary, and somehow managed to just "get it" and
> instantly, in a flash of insight, come up with "the solution" for version
> control.

Wait, what? Git was the response from Torvalds to BitKeeper being proprietary
and the author being upset with some kernel developers. It's basically taking
what was then state of the art for DCVS and reimplementing it, not coming up
with some new paradigm. It's a good program, and to my knowledge it was
engineered well, but let's not rewrite history so Torvalds is the father of
DVCS.

~~~
beagle3
Linus was moving off of BitKeeper, which obviously was some of the inspiration
for git - but the underlying model is nothing alike. Git's data model is much
simpler than CVS, RCS, Subversion, BitKeeper and basically anything else that
existed at the time, and it was also much faster. The command line interface
doesn't reflect this properly, but it's the underlying model that counts.

Git is nothing like a reimplementation of BitKeeper - the closest inspiration
and model is actaually Monotone, which had the same basic concepts but was
slow and clunky. IIRC, Torvalds credited monotone/Hoare for using merkle trees
(and other things)

~~~
tomjakubowski
> The command line interface doesn't reflect this properly, but it's the
> underlying model that counts.

Could you explain why, for a tool meant to be used by humans, the underlying
model (which I agree is very elegant) counts more than the user interface?

~~~
gcp
_the underlying model (which I agree is very elegant) counts more than the
user interface?_

It does not. But git exposes this all the time, so committed git users feel
that's a good thing, because understanding it makes helps them to make sense
of some of the worst parts of the UX.

~~~
FatalBaboon
Git is the reference implementation of a protocol, and much like HTTP, you
must learn it the hard way if you intend to be a professional in the domain.

The mistake is to believe there is a U<I|X> in the first place.

It does not, however, stop you from using one of the many graphical tools,
that are fine for simple usage and will all eventually fall short.

You could use a GUI to make complex HTTP routes, through proxies and DNS
records via drag&drop, and then one day you'll have some weird DNSSEC error
that the maintainer does not care about, and you will have to explain that to
whoever is losing money.

Acknowledging a problem is not as trivial as it was first thought is critical
in our line of work in my opinion.

~~~
gcp
_Git is the reference implementation of a protocol_

In reality this "reference implementation" is the sole interface 99% of the
users use, so the lack of UX _is_ an issue.

There are other tools that do it better and right, so insisting that there's
any redeeming qualities to git here is being blind to the obvious. There's
actual academic research describing git's problems here, for crying out loud.

~~~
glandium
> There's actual academic research describing git's problems here, for crying
> out loud.

And interestingly, all the academic research talks about is the high level UI.
Not the underlying data model.

> In reality this "reference implementation" is the sole interface 99% of the
> users use

/That/ is the mystery to me. I don't see a reason why a better UX around the
same underlying data model, talking to the same server (and thus interacting
natively with e.g. github) hasn't picked up.

Heck, one could implement mercurial's UX on top of the git data model. In
fact, that even has been prototyped. I can't find the repository anymore, but
iirc it was somewhere on bitbucket.

~~~
beagle3
There are at least five such front ends (easygit comes to mind) and extensions
(like legit from Kenneth Reitz). But none is popular, and I suspect the reason
is that, despite all the complaining, Git's default UI is not actually that
bad in day to day use.

------
dasil003
Were a lot of programmers really hung up on this idea of having increasingly
smart merge algorithms back then? What Linus says seems self-evident to me: if
there's even a whiff of a conflict, I want it to be shown to me so I can make
a human decision about it. A merge algorithm smart enough to resolve every
case is easily proven to be impossible by the fact that it's possible for
branches to merge cleanly with no conflict, _and yet still have a logical
conflict_ due to some implicit contract that was broken. These are the
nastiest regressions to find, and one reason I insist on rebasing before
merging topic branches, because then at least git-bisect will tell you where
the implicit contract was broken precisely on the second-rebased-and-merged
branch. Smarter merge algorithms would just paper over more problems and so
you quickly hit diminishing and then negative returns by trying to be too
clever.

~~~
gcp
You can still verify the result of an automatic merge. It's simpler to mark a
suggestion "y" than to resolve conflicts that could be solved automatically by
hand.

So I don't think this reasoning holds any ground whatsoever.

~~~
andrewflnr
You're not actually contradicting GP. Marking a suggestion "y" is still making
a human decision, just with really good auto-complete.

~~~
gcp
Look into the actual posts, it was used as an argument to dismiss smarter
merge algorithms which is of course the smarter auto-complete part.

~~~
andrewflnr
What they're actually objecting to of the idea of not having a human in the
loop. I suspect if you pitched these smart merge algorithms from the "click to
accept auto merge" angle, they wouldn't have much of a problem. Instead they
seem to be pushed as a way of avoiding interaction.

------
phkahler
If Linus had insight into issues around merging it's because that's what he
does for a living. Every change to the Linux Kernel is ultimately
approved/merged by him. Think about that. More than any person on earth, Linus
knew what the issues involved with DVCS were and he chose a solution that fit
all the use cases he saw on a daily basis.

~~~
yes_or_gnome
He's not even a top 20 approver. Greg KH takes those honors, Andrew Morton is
number 3, and I forget the rest. The list comes out annually from the Linux
Foundation. (Sorry, no link.) The foundation requires an email address and
credentials before providing access to the pdf.

During the merge window, Linus takes in most of changes for the next kernel
release. All of which have been approved by someone else. With each RC
release, the lieutenants still approve most of the new changes. It's a matter
of when a crucial fix is needed for Linus's mainline kernel, then he'll accept
a commit directly.

------
mkj
The merge algorithm
[http://wiki.monotone.ca/MarkMerge/](http://wiki.monotone.ca/MarkMerge/) used
by Monotone has a well defined user model for conflicts, with similarity to
Codeville's merge algorithm iirc. I'm not sure if any later VCS used it, looks
like perhaps not.

~~~
tbrownaw
Mark-merge is specifically for standalone scalar values. We used it for tree
structure (file name, and patent directory), for file attributes, and as a
first pass on file content to see if we needed to bother doing a 3-way
message.

Tree structure is overrated. The way git handles it works better in practice.
Files are an implementation detail, rather than something fundamental about
code structure.

Using it as a first pass at content merging was mostly a performance
optimization, and also only works if you track individual files as objects.

It _might_ be a useful building block for a system that tracks refactorings as
fundamental operations and knows how to do merges on your AST instead of on
the serialized text form of your choice. But as far as I know no such system
exists yet, and merging complex data structures is far more complex than
simply merging their individual building blocks.

------
j1vms
Looking at the exchange a bit and reviewing the context in which it occurred:
it's a great example of someone clearly deciding what problem they want to
fix, followed by defining their priorities and sticking to them. As Linux has
pointed out (IIRC), doing this pointed the way toward the underlying data
structures, and the algorithms to manipulate this data followed from there.

Cohen, as remarkable as always, comes across in this instance as trying to
"sell" his product (codeville) and taking it a little personally when Linus
isn't swayed. Linus clearly defines the problem he was trying to solve, and
believes that git solves it better than codeville. He would have backed
codeville if he thought it met kernel dev needs better than git. After all, he
had jumped on Bitkeeper before, against other people's wishes.

------
integricho
Is there any information on when exactly / and for what exact reasons was
codeville development abandoned?

------
acqq
The link to the relevant response of Linus Torvalds about his design:

[http://www.gelato.unsw.edu.au/archives/git/0504/2178.html](http://www.gelato.unsw.edu.au/archives/git/0504/2178.html)

~~~
nicky0
I like this nugget from the post:

"It's sometimes better to know that you don't know the answer, than it is to
_think_ that you know the answer."

\- Linus Torvalds

~~~
acqq
If you'd try to find the roots of that idea, it would certainly be at least
hundreds of years old, reflecting the difference between the scientific and
the religious approaches to the world.

~~~
ttctciyf
At least as old as Plato:

"I am wiser than this man, for neither of us appears to know anything great
and good; but he fancies he knows something, although he knows nothing;
whereas I, as I do not know anything, so I do not fancy I do. In this trifling
particular, then, I appear to be wiser than he, because I do not fancy I know
what I do not know."

Plato: Apology, ~ 400BC

~~~
vacri
Which is actually romantic nonsense, just like those people who say in the
modern world that "we know nothing about how things work". We know plenty. We
just don't know it all.

A man who says he knows _something_ is also being less of a wanker than a man
who says he knows _nothing_ , especially if the latter then uses that comment
as leverage to claim wisdom over the former.

~~~
acqq
Read more from the original, taking just a small quote out of it doesn't do it
justice. Also see my other comment for the context. The context matters.

It's about the claims based on faith versus the acknowledging the scope of
what we actually know so that we can actually find out, which produces the
absurdities in the religions for which they have to shame themselves today, as
these simply don't match what we know today for sure.

Socrates was sentenced to death for impiety, that's the part of his own,
obviously unsuccessful, defense.

~~~
vacri
I indeed haven't read the original. In context, it may make sense, but
certainly pulled out of context like this, it's romantic twaddle.

Whenever I hear a person say that 'we really know nothing', it always reminds
me of Insane Clown Posse being angry that science has an explanation for how
magnets work... as in, finding comfort in expressing ignorance :)

~~~
acqq
Well, what's true is that these particular sentences were often not only used
out of the context but even particularly modified to the significantly
different "I know that I know nothing."

[https://en.wikipedia.org/wiki/I_know_that_I_know_nothing](https://en.wikipedia.org/wiki/I_know_that_I_know_nothing)

"Evidence that Socrates does not actually claim to know nothing can be found
at Apology 29b-c, where he claims twice to know something. See also Apology
29d, where Socrates indicates that he is so confident in his claim to
knowledge at 29b-c that he is willing to die for it."

So he was what we'd today call "a scientist" being ready to admit the changing
but the finite limits of the knowledge while acquiring the new knowledge, not
"an ignorant."

But it's also not surprising that not everybody even understood what was that
about.

------
vacri
Yet another description of "Linus and his fireworks", and when you actually
read the thread, there's a little bit of crankiness, yes, but mostly a lot of
discussion. It's milder than what goes on in a lot of HN threads.

Damn people love this trope.

------
asmosoinio
To anyone else wondering: "Codeville was a distributed revision control
system" \-
[https://en.wikipedia.org/wiki/Codeville](https://en.wikipedia.org/wiki/Codeville)

~~~
nix0n
Also, Bram Cohen's diff algorithm made it into Canonical's Bazaar VCS. I think
some of the Cohens' other VCS ideas may have made it into Bazaar, but I'm not
sure.

------
pawadu
This reminds me of that old discussion between Linus and ESR where the ESR
tries really hard and has a lot of really good arguments but Linux doesn't
care because he is right.

The thread was on HN last year, I think the title was something about Linus
being to smart for his own good or something similar.

edit: "The curse of the gifted programmer (2000)",
[https://news.ycombinator.com/item?id=11077799](https://news.ycombinator.com/item?id=11077799)

------
SadWebDeveloper
Git is popular (nowadays), it's a decent DVCS that requires craftmanship and
tons of trials and errors before you can consider yourself "pro user" and it's
funny that the go to solution for all git problems it's still "just hard reset
your repo".

------
rincebrain
Since this 404s for me (or, more evilly, says "200 OK" in HTTP and "Not Found"
on the page), have a cache link:
[https://webcache.googleusercontent.com/search?q=cache:7Qj5RC...](https://webcache.googleusercontent.com/search?q=cache:7Qj5RCqa56YJ:www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php+&cd=1&hl=en&ct=clnk&gl=us)

Bonus: the two times this link showed up on HN before and got more than a
couple of comments:

[https://news.ycombinator.com/item?id=8118817](https://news.ycombinator.com/item?id=8118817)

[https://news.ycombinator.com/item?id=505876](https://news.ycombinator.com/item?id=505876)

~~~
walrus
You probably have HTTPS Everywhere installed.

~~~
rincebrain
You would be correct. I suppose the SSL vhost is just tragically broken, then.

------
qplex
Article from 2007.

------
tehabe
Not Found. Were there any interesting points mentioned?

~~~
gcp
No, it's pure fanboying. The rename behavior in particular is still not a
settled issue.

