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

[Thomas Lord]

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