Re: Bugs with detection of renames that are also overwrites

From: Anders Kaseorg <andersk@mit.edu>
Date: Feb 23, 2010, 19:08 UTC
Message-ID: <alpine.DEB.2.00.1002231336310.14055@dr-wily.mit.edu>
In-Reply-To: <20100223122257.GA1735@coredump.intra.peff.net>

On Tue, 23 Feb 2010, Jeff King wrote:

Show 13 quoted lines

> > Therefore, the patch can’t be applied to its own source tree.
> > 
> > $ git checkout foo
> > $ git diff -M -B foo bar | git apply
> > error: b: already exists in working directory
> 
> Hmm. I think this is a conflict between what the user wants to see and
> what apply wants to see. From the user's perspective, thinking about the
> diff representing a change, "b" was not really deleted. It was simply
> overwritten. But from apply's perspective, the diff is a set of
> instructions, and those instructions do not mention that "b" previously
> existed and was overwritten. So it is right to be cautious and declare a
> conflict.

I agree; git apply has no choice given that input.

Show 5 quoted lines

> I'm not sure just throwing a "delete" line in there would be the best
> thing, though. The instructions for apply really need to be "if 'b' has
> this sha1, then it is safe to delete and rename a into place. Otherwise
> it is a conflict". And I'm not sure how we would represent that (I guess
> with a full diff and an "index" line).

Yeah, a full diff is the only sane solution, just like it is for plain deletes. Otherwise the patch could not be reverse-applied. (If the user really doesn’t want to see the deletion, they can use --diff-filter.)

diff --git a/b b/b
deleted file mode 100644
index 3d47ea7..0000000
--- a/b
+++ /dev/null
@@ -1,101 +0,0 @@
-300
-301
…
-399
-400
diff --git a/a b/b
similarity index 100%
rename from a
rename to b

This patch is already handled correctly by git apply (and git apply -R), 
as long as the rename is listed after the delete.

Anders