Re: git diff: add option for omitting the contents of deletes

> On Mon, Feb 28, 2011 at 07:17:26AM -0500, Jeff King wrote:
> 
>>> That aspect is similar to -M and -C, though - unless we check the sha1
>>> of the blobs before applying the patch (which would be possible for -D
>>> also) - do we?
>>
>> Yes, I think we do check the sha1s for a "-M" patch. And we should do so
>> for a "-D" patch, too. Which would make it just as likely to conflict as
>> a version with the actual patch content, _except_ that it relies on the
>> recipient having that sha1.
>>
>> I don't see how "-D" is any less reversible than -M or -C, though. If I
>> get your -D patch, I use the index line to see that the blob went from
>> 1234abcd to 0000000, check that we are at 1234abcd, and then delete the
>> file. To reverse it, I reinstate 1234abcd from nothing (and conflict if
>> the file exists). _Neither_ case works without the sha1.
>>
>> So I think the problem is not about "this cannot be reversed" but about
>> "the recipient must have your sha1 to make sense of it, in either
>> direction". Which is the same case as with "-M" and "-C", and why we
>> have long cautioned about their use on mailing lists. But the right rule
>> is not "do not use on mailing lists" but rather "do not use on mailing
>> lists for projects where the recipients will not be using git to apply".
> 
> Actually, thinking on this a bit more, I guess "-M" and "-C" are usable
> without the sha1. In fact, we don't even provide it for a strict 100%
> rename, and for a rename-with-patch, you can apply the patch, assuming
> you have the original file in any form. So they are really about "is
> your recipient using git", not "is your recipient using git _and_ will
> he/she have the right sha1".