Jakub Narebski <jnareb@gmail.com> writes:

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html