Subject: Re: Bugs with detection of renames that are also overwrites
Newsgroups: gmane.comp.version-control.git
Date: 2010-02-23 19:08:36 GMT (1 year, 50 weeks, 2 days, 16 hours and 33 minutes ago)
On Tue, 23 Feb 2010, Jeff King wrote: > > 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