Jakub Narebski <jnareb@xxxxxxxxx> writes: > What about the fact that git-diff -M is _not_ patch-compatibile; What about it? I've never said patch compatibility is an issue. We have something patch cannot represent or understand and you should admit it. The point is to make it easier to massage by hand, when the recipient does not have git handy. With -M, the recipient can read and understand the patch text better than "remove this oldfile and create this newfile that the diff output does not tell you is related" diff. And we say "rename" in plain language so the recipient _can_ do "mv A B" then "patch -p1". Similarly, with -T that changes a symlink into a real file, if we do not do the current "remove the old and then create the new" and did instead "show the textual diff that can be applied", a non-git tool that does not understand the typechange can mistakenly muck with the target of the symlink, which is a disaster. "Remove the target and then create this" at least would have lesser damage -- the object left as the result is incorrect nevertheless, but reading the contents and creating a symlink that has that contents by hand is easily done in a pinch. > We should have whatchanged part corresponding to the patchset > part at least in "commitdiff" view, which means '-c' (and for > the time being perhaps mean '-c' also in patchset part). '--cc' > which uses '-c' for the raw part would be nice... I am not sure what you mean by patchset part, but if you are talking about the multiway diff text, I think most of the time output from "-c -p" is much less interesting than "--cc". - 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