Re: [Gnu-arch-users] Type-specific diff & patch

[Thomas Lord]

Stefan Monnier wrote:
> And sanity says that if you want funny merge tools, you should separate the
> notion of an internal patch (only used internally by applying it to the
> original base file, in order to recreate a specific revision), from the
> notion of an external patch (potentially applied by cherry picking, or
> something like that).  An external patch can always be generated from the
> internal one.
>
>   
A couple of thoughts:

First, in general, I like the idea of separating out functionality.  Arch 1
wound up being too much of a monolith -- everything is hoplessly
intertwingled in one big tool.   My bad.

Second, I think there are three uses for -- let's call them deltas -- in 
an RCS:

 1. Delta-compressed Storage

 2. Some kinds of merging, especially cherry-picking.

Those are pretty obvious.   The third one is one I think people tend to
overlook:

 3. Signing and review.

When I commit a revision, sure, I am saying "Hey, I commit this tree
in exactly such and such a state."   The whole tree is one of the things
I sign.  I certify that "Yeah, I think this tree is what I meant."

However, when I commit a revision very often what I *mean* is:
"I intend the following *changes*."   Signing a delta, rather than
a whole tree, *can* have a more useful meaning.   It's a more
direct expression of reality, at least sometimes.

Now, of course, we all know that revision deltas and whole trees
form a dual space.   Given two adjacent revisions you can compute
the delta from scratch.  Given either tree and a delta, you can get
the other delta.

It's a mistake, though, to say it makes no difference whether the user
commits a tree or delta.     The symmetry between trees and deltas
is broken by the question:

    What did the user *sign*?  The tree?  The delta?  Both?

My view is that *in some cases*, a signed delta is a good form
of formal communication by a user.   Before the commit, the
user can review the delta.   The user can even write a log
comment that explains the delta line by line.   The user can make
sure that the automagically computed delta is, on its own or in
combination with the log message, expressive of an idea.   A third
party can read a delta like a piece of writing.

Conversely, if user's only ever commit trees -- it's a little ambiguous.
I can compute my own delta from those trees but ... are those
changes really what the committing user meant?  Or maybe there
was an accident in there?   Or maybe my diff tool works differently
from his so I'm seeing something he didn't?

It's a fine point, I admit.  It presumes kinds of review that mostly
don't happen (currently) in the real world.    It's just that I think
these kinds of review are very valuable.   If Arch can lead some
users to use this kind of feature, and they gain an advantage,
that's a win.

-t