diff options
author | Junio C Hamano <gitster@pobox.com> | 2008-07-09 19:58:23 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2008-07-09 20:31:44 -0700 |
commit | a9a3e82e6d0018ff42ec11fd9560c1ff47add824 (patch) | |
tree | 4a7bd524b0f232513255daf7d1f9b430405749e8 /t/t9001-send-email.sh | |
parent | 7eef32d9f4883d983e284f5c508a92833bd89d11 (diff) | |
download | git-a9a3e82e6d0018ff42ec11fd9560c1ff47add824.tar.gz git-a9a3e82e6d0018ff42ec11fd9560c1ff47add824.tar.xz |
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>
Diffstat (limited to 't/t9001-send-email.sh')
0 files changed, 0 insertions, 0 deletions