Revision 6aba117d5cf7128e7bc942888263552fe927e13f authored by Elijah Newren on 29 August 2018, 07:06:13 UTC, committed by Junio C Hamano on 30 August 2018, 14:58:59 UTC
Let's say you have the following three trees, where Base is from one commit
behind either master or branch:

   Base  : bar_v1, foo/{file1, file2, file3}
   branch: bar_v2, foo/{file1, file2},       goo/file3
   master: bar_v3, foo/{file1, file2, file3}

Using git-am (or am-based rebase) to apply the changes from branch onto
master results in the following tree:

   Result: bar_merged, goo/{file1, file2, file3}

This is not what users want; they did not rename foo/ -> goo/, they only
renamed one file within that directory.  The reason this happens is am
constructs fake trees (via build_fake_ancestor()) of the following form:

   Base_bfa  : bar_v1, foo/file3
   branch_bfa: bar_v2, goo/file3

Combining these two trees with master's tree:

   master: bar_v3, foo/{file1, file2, file3},

You can see that merge_recursive_generic() would see branch_bfa as renaming
foo/ -> goo/, and master as just adding both foo/file1 and foo/file2.  As
such, it ends up with goo/{file1, file2, file3}

The core problem is that am does not have access to the original trees; it
can only construct trees using the blobs involved in the patch.  As such,
it is not safe to perform directory rename detection within am -3.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 5fdddd9
History
File Mode Size
LICENSE -rw-r--r-- 1.5 KB
fast_export.c -rw-r--r-- 9.7 KB
fast_export.h -rw-r--r-- 1.4 KB
line_buffer.c -rw-r--r-- 2.8 KB
line_buffer.h -rw-r--r-- 980 bytes
line_buffer.txt -rw-r--r-- 2.4 KB
sliding_window.c -rw-r--r-- 2.0 KB
sliding_window.h -rw-r--r-- 376 bytes
svndiff.c -rw-r--r-- 8.0 KB
svndiff.h -rw-r--r-- 210 bytes
svndump.c -rw-r--r-- 13.4 KB
svndump.h -rw-r--r-- 267 bytes

back to top