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

[Jeff King <peff@peff.net>]

On Mon, Feb 28, 2011 at 01:32:35PM +0100, Michael J Gruber wrote:

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