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

On Mon, Feb 28, 2011 at 07:17:26AM -0500, Jeff King wrote:

quoted

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

I do still think that in practice among git users that "-D" patches will
be able to be applied. You won't typically be sending a patch to delete
something that other people don't have. I would expect most uses of
"apply -R" to be reverting an existing delete, which means you will have
the sha1.

-Peff