Jeff King venit, vidit, dixit 28.02.2011 13:23: > 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". $ git mv Makefile Dofile $ git staged # yadayada diff --git c/Makefile i/Dofile similarity index 100% rename from Makefile rename to Dofile Same with copy. But that's not good, is it? I mean, Alice sends me her "copy patch" and I send her my Makefile patch, both on top of the same base. We both apply each other's patch cleanly. We end up with different "Dofile". Checking the sha1 would prevent this. It's no surprise that patch application is non-commutative, but shouldn't we catch this? Michael -- 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