]> git.ipfire.org Git - thirdparty/git.git/commit - t/t4112-apply-renames.sh
apply: fix copy/rename breakage
authorJunio C Hamano <gitster@pobox.com>
Thu, 10 Jul 2008 02:58:23 +0000 (19:58 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 10 Jul 2008 03:31:44 +0000 (20:31 -0700)
commita9a3e82e6d0018ff42ec11fd9560c1ff47add824
tree4a7bd524b0f232513255daf7d1f9b430405749e8
parent7eef32d9f4883d983e284f5c508a92833bd89d11
apply: fix copy/rename breakage

7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to
grok a (non-git) patch that is a concatenation of separate patches that
touch the same file number of times, by recording the postimage of patch
application of previous round and using it as the preimage for later
rounds.

This "incremental" mode of patch application fundamentally contradicts
with the way git rename/copy patches are designed.  When a git patch talks
about a file A getting modified, and a new file B created out of A, like
this:

diff --git a/A b/A
--- a/A
+++ b/A
... change text here ...
diff --git a/A b/B
copy from A
copy to B
--- a/A
+++ b/B
... change text here ...

the second change to produce B does not depend on what is done to A with
the first change in any way.  This is explicitly done so for reviewability
of individual patches.

With this commit, we do not look at 'fn_table' that records the postimage
of previous round when applying a patch to produce a new file out of an
existing file.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-apply.c
t/t4112-apply-renames.sh