Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

John Fremlin writes:
 > Stephen J. Turnbull wrote:
 > > Of course.  In a sense every VCS must have an implicit theory of
 > > patches (and unfortunately in Darcs's case, it doesn't entirely match
 > > the explicit one).
 > 
 > Where does the implicit theory of patches diverge from the explicit (and 
 >   misguided) one?

The assumption that two changes which conflict partially but are
identical on the conflict are not in conflict.  David originally had
this right but eventually bowed to pressure from the peanut gallery.

 > To achieve darcs' goals, it would have to understand rather more about 
 > the meaning of the changes than it currently does or is feasible. This 
 > would involve a very interesting and much more language-specific theory 
 > of patches.

Which is what I said elsewhere, in different words.

 > > Unfortunately for git's theory, it suffers from the same bug that
 > > Darcs does, namely the assumption that changes that do not conflict
 > > textually do not conflict semantically.  For example, it's quite
 > > possible in git to commit a change to a function prototype in foo.h
 > > without making the corresponding change in foo.c or in any callers.
 > > You will of course get no warning until you compile.
 > 
 > That is not exactly what I was trying to get at.
 > 
 > Namely, I think the idea of operation of git is that major changes have 
 > their own branch name and are regularly rebased onto the master branch 
 > and then eventually merged.
 > 
 > There isn't any need for the machine to worry about whether one branch 
 > conflicts with another, that's for the user to figure out.

Of course git has to worry about conflicts.  If it didn't, there would
be no need for git-rebase --continue and/or git-rebase --skip.

 > Therefore, git hasn't claimed anything that it cannot deliver -- it's 
 > theory is all about how it manages its database, and is correct.

Well, sure.  If you say "anything I don't get right is the user's
fault," then of course you're not going to ever get anything wrong.
But git doesn't do that.

What git gets right here is that it is so cheap to keep *every
change*, whether it conflicts with an existing branch or not, and if
you're even a little bit worried, you can make a branch (or stash).
What git really needs is the ability to listen to the programmer
muttering under his breath and turn that into commit logs every 15
seconds or so. :-)

 > > Now, if you're Linus (or on a more personal note, Curt), you can keep
 > > all that in your head.  I think that's why Curt can get away with
 > > deprecating cheap branching as he did.  But when you get to the scale
 > > of the Linux kernel, it don't work so well, and you start needing
 > > cheaping branching so bad you invent it. :-)
 > 
 > Even with smaller scale projects (four or five people) it's incredibly 
 > useful to be able to branch quickly to make changes that benefit one 
 > feature but break a lot of others.

In case it wasn't obvious, my statement about keeping it in your head
was restricted to values of "you" in {Linus, Curt}.  Me?  I'm with
you.  In fact, I commit on *every save* (automatically, on a hook),
and I'm thinking about extending that to autosaves, although that's
probably overkill.

 > The theory of git would involve a lot of talk about blobs and checksums, 
 > so you are quite right that it shouldn't be called a theory of patches 
 > but something else.

Heh.  It's a lot easier than that.  Git is a specialized Lisp with
annotated conses (commits), multiway trees (trees), symbols (tags),
and hash tables with stable universal hashes (all objects).  All done! 
Look Ma: no lambdas, and no parentheses.  I'm in heaven! :-)