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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 28, 2011, 13:05 UTC
Message-ID: <4D6B9DA1.4070805@drmicha.warpmail.net>
In-Reply-To: <20110228125909.GA9054@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 28.02.2011 13:59:

Show 34 quoted lines

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

When I said "copy patch" I actually meant a patch which records the copy "Makefile -> Dofile". What is it today? Is it me? I know I wrote the "mv" example first, but still :)

I mean, Alice: cp Makefile Dofile sends me a -C patch

I: Break everything by hacking Makefile send her a crappy patch

Both: apply the received patch

Now I end up with a borked Makefile and a borked Dofile, but Alice still has a good Dofile, and it's all my fault, so I don't deserve any better. But still.

Show 9 quoted lines

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

I think so. (Or make -f force it.)

This is orthogonal to the "-D" suggestion", but "-D" could write the index line to start with.

Michael