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
_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
