Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

Stephen J. Turnbull wrote:
> John Fremlin writes:
[...]
>  > 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.

Why do you think one way is more correct than another and how does this 
relate at all to the theory?

The theory works fine provided the black box that determines whether 
patches conflict is "reasonable" -- I'm not sure of the exact conditions 
-- are you saying they are violated by this the choice of allowing 
patches that share a common implied patch to commute or not?

I don't see this at all, sorry for being so slow -- can you explain?

On a related note http://projects.haskell.org/camp/

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

Great, we agree on something :-)

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

It doesn't worry about it, it let's the users deal with it and provides 
tools to help them.

Darcs is explicitly designed to worry about 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.

For a concrete example:

At a previous job I was simultaneously rewriting the H.264 deblocking 
code to allow us to process images in stripes in local memory, and 
abstracting access to DMA so multiple drivers/applications could share a 
channel, and occasionally bugfixing stuff in the normal tree.

As the H.264 stuff used DMA, these two changes had to have separate 
branches (in fact as we used CVS, I actually just checked out versions 
of the source tree into different directories).

The DMA stuff was very useful for the projects which were using 
supported drivers and where they were short of DMA channels, but not for 
everybody as not all drivers were converted. So it couldn't be committed 
to the trunk for a while.

How would Curt or Linus keep this in their heads?

>  > 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! :-)

But git's database is not a programming language so that doesn't make 
sense. The difference between Lispy languages and others is that in Lisp 
code is a singly linked list and can be fiddled with as if were data.

You could equally well claim that git was a specialised Python.