Junio C Hamano wrote:
quoted text
> Jakub Narebski <jnareb@gmail.com> 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.

So we split patch for "type change" mode change for patch -p1
safety. But for gitweb more important than producing safe patch
is producing _readable_ patch[*1*]. Hence request for -T option 
(or under other, better name) to git-diff which would _not_
split patch (not create two patches for one raw difftree line).
 
[*1*] Well, as far as diff for symlink is readable anyway.

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".

Sorry, perhaps I was not clear. I'd like for git-diff-tree --cc
--raw -p to output both raw part (perhaps taken from -c) and
patch part[*2*]. Gitweb needs raw part for both whatchanged 
and also for creating hyperlinks and gitweb quoted filenames
in the patch part (although with git diff headers buffering
and git diff extended headers parsing we could get the information
needed for hyperlinks and gitweb quoting of filenames for patch
part from patch part).

[*2*] I'm wondering why we don't have --patch long version of -p
option to git-diff[-tree].

-- 
Jakub Narebski
Poland
-
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