On Mon, Feb 28, 2011 at 01:32:35PM +0100, Michael J Gruber wrote:
quoted hunk ↗ jump to hunk
quoted
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?
Won't you either get a conflict or end up with the same Dofile? Clearly
you will have a Dofile with your Makefile changes, as you applied the
movement on top of your changes.
Alice will either:
1. Apply not using rename detection (e.g., not using git, or using
"git am" without "-3"). In this case, she gets a conflict because
she no longer has Makefile.
2. Apply using rename detection (e.g., via "git am -3"). In this case,
we will notice the movement of Makefile to Dofile, and apply the
patch to Dofile.
Still, I do wonder if we should be including an index line on a straight
rename patch. It lets the recipient check that what is being renamed is
what they have (IOW, it gives the same check that they would do if they
ahd the whole patch text). And then the recipient can decide how to
resolve the conflict.
-Peff