Re: Bugs with detection of renames that are also overwrites

On Tue, 23 Feb 2010, Jeff King wrote:

quoted

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.

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