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