"Shawn O. Pearce" <spearce@spearce.org> writes:

quoted text
> Yea, this I like even better than what I posted.  Now we just need
> a suck^H^H^H^Hprogrammer to implement a working prototype and see
> how folks like more realistic diffs generated with it.  ;-)

I have to disgree.

We on the git list *live* in pretty much git-only world (ok, I
am ignoring git-svn people for now ;-)), so it might feel it
beneficial to add a new output format to git-diff.

But many users of git generated patch needs to interact with
patches that are not generated by git.  I think an additional
postprocessor in patchutils/interdiff toolchest would probably
make much more sense.  Then a person who reviews a patch that is
supposed to be line movement can use the filter to verify the
parts that should be only line movements are indeed are
movements and nothing else.

Speaking of "diff" output, what I would like to see is a support
of 'copied context' (i.e. traditional 'context diff' format you
would get from "diff -c"), in addition to the 'unified context'
we support.  Generating copied context may help people who need
to give patches to others that accept only copied context format
patches (are there important projects that take only cpied
context format patches?).  Being able to accept copied context
format patches in 'git-apply' would also be handy.

Of course, we could use interdiff to mangle copied context
format into unified context format, so 'git-apply' is not a big
deal, though.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html