Re: Type-specific diff & patch

Ludovic Courtès wrote:
> File-specific diff would be feasible in Arch 1, and it'd be nice to do
> it (I meant to give it a try but haven't had time so far).
>   
Some thoughts for this particular soup:

* define what "a patch" is

  If there are lots of tools for computing and applying patches, what must
  they have in common?   I think the answer is that a patch is an
  Tree->Tree transform which can usefully be applied precisely or
   imprecisely, that is invertible when applied precisely, and that can
   be composed with other patches to form a new patch.

   "Precise" patch application is, of course, applying a patch to the ORIG
   tree you started from and is described by the identity:

        Tree_b == ApplyPatch (Diff(Tree_a, Tree_b), Tree_a)

   "Invertible" means:
 
        Tree_a == ApplyPatch (Inverse(Diff (Tree_a, Tree_b)), Tree_b)

    "Composable" means:

         Tree_c == ApplyPatch (P, Tree_a) where
            P is Compose(Diff(Tree_a,Tree_b), Diff(Tree_b, Tree_c))

  Note that the compose of two patches or the inverse of any patch
  must itself be a patch that also has all of these properties.

  Why does that matter?  Well, one reason:

* Wouldn't it be nice, if....

   Sometimes a `commit', even for ordinary source code, represents
   a simple but systematic change for which line-oriented diff/patch
   is completely the wrong way to summarize the change.   An example:

   Suppose my program has function `foo' which takes two parameters.
   I want to add a third parameter which, in all existing calls, should 
default
   to FOO_DFLT.   But later, I might add new calls that take a different 
value.

   It isn't hard to imagine a tool that takes a description about like 
that.  "Add an
   extra parameter to calls to `foo', passing FOO_DFLT."   Why have hundreds
   or thousands of lines of `diff(1)' output when such a short 
description is
   completely accurate and better summarizes the changes in the commit?

  I'm vaguely aware that Eclipse has program transform features like this.
  I'm vaguely aware that extreme/agile programming methodology encourages
  transforms like this (and so wants tools for it).

   Can we say how to apply such a patch imprecisely?  Sure: signal a 
conflict
   for any call to `foo' that isn't starting from two parameters.

   Can we say how to reverse it?  Sure: remove cases where FOO_DFLT is
   passed and signal a conflict if some other value is passed.

   So:

* Per-file methods?  Or Per-intention?

   I'd nearly always want to use, say, an XML-specific diff/patch for 
some kinds of
   file -- so per-file is a good idea.

   What about per-intention, though?   Normally I want to use 
line-oriented diff/patch
    for .c files but, for some commits, maybe I'd rather use the 
program-transform tool
    knows how to add an extra parameter to caller's of `foo'.

* But What's the Workflow?

   Would this really fit usefully into something like Eclipse or into 
the existing
    practices of extreme/agile practitioners?   What would it take?

   Does the "checkout-edit-commit" paradigm really always make sense?  Maybe
   there's a need for an option to "checkout-transform-approve-commit" 
with no
   by-hand editing mixed in.

-t