"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
