2011-08-12 05:19:34 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description="recursive merge corner cases w/ renames but not criss-crosses"
|
|
|
|
|
# t6036 has corner cases that involve both criss-cross merges and renames
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/delete + untracked file' '
|
|
|
|
|
echo "A pretty inscription" >ring &&
|
|
|
|
|
git add ring &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m beginning &&
|
|
|
|
|
|
|
|
|
|
git branch people &&
|
|
|
|
|
git checkout -b rename-the-ring &&
|
|
|
|
|
git mv ring one-ring-to-rule-them-all &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m fullname &&
|
|
|
|
|
|
|
|
|
|
git checkout people &&
|
|
|
|
|
git rm ring &&
|
|
|
|
|
echo gollum >owner &&
|
|
|
|
|
git add owner &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m track-people-instead-of-objects &&
|
|
|
|
|
echo "Myyy PRECIOUSSS" >ring
|
|
|
|
|
'
|
|
|
|
|
|
merge-recursive: Fix deletion of untracked file in rename/delete conflicts
In the recursive case (o->call_depth > 0), we do not modify the working
directory. However, when o->call_depth==0, file renames can mean we need
to delete the old filename from the working copy. Since there have been
lots of changes and mistakes here, let's go through the details. Let's
start with a simple explanation of what we are trying to achieve:
Original goal: If a file is renamed on the side of history being merged
into head, the filename serving as the source of that rename needs to be
removed from the working directory.
The path to getting the above statement implemented in merge-recursive took
several steps. The relevant bits of code may be instructive to keep in
mind for the explanation, especially since an English-only description
involves double negatives that are hard to follow. These bits of code are:
int remove_file(..., const char *path, int no_wd)
{
...
int update_working_directory = !o->call_depth && !no_wd;
and
remove_file(o, 1, ren1_src, <expression>);
Where the choice for <expression> has morphed over time:
65ac6e9 (merge-recursive: adjust to loosened "working file clobbered"
check 2006-10-27), introduced the "no_wd" parameter to remove_file() and
used "1" for <expression>. This meant ren1_src was never deleted, leaving
it around in the working copy.
In 8371234 (Remove uncontested renamed files during merge. 2006-12-13),
<expression> was changed to "index_only" (where index_only ==
!!o->call_depth; see b7fa51da). This was equivalent to using "0" for
<expression> (due to the early logic in remove_file), and is orthogonal to
the condition we actually want to check at this point; it resulted in the
source file being removed except when index_only was false. This was
problematic because the file could have been renamed on the side of history
including head, in which case ren1_src could correspond to an untracked
file that should not be deleted.
In 183d797 (Keep untracked files not involved in a merge. 2007-02-04),
<expression> was changed to "index_only || stage == 3". While this gives
correct behavior, the "index_only ||" portion of <expression> is
unnecessary and makes the code slightly harder to follow.
There were also two further changes to this expression, though without
any change in behavior. First in b7fa51d (merge-recursive: get rid of the
index_only global variable 2008-09-02), it was changed to "o->call_depth
|| stage == 3". (index_only == !!o->call_depth). Later, in 41d70bd6
(merge-recursive: Small code clarification -- variable name and comments),
this was changed to "o->call_depth || renamed_stage == 2" (where stage was
renamed to other_stage and renamed_stage == other_stage ^ 1).
So we ended with <expression> being "o->call_depth || renamed_stage == 2".
But the "o->call_depth ||" piece was unnecessary. We can remove it,
leaving us with <expression> being "renamed_stage == 2". This doesn't
change behavior at all, but it makes the code clearer. Which is good,
because it's about to get uglier.
Corrected goal: If a file is renamed on the side of history being merged
into head, the filename serving as the source of that rename needs to be
removed from the working directory *IF* that file is tracked in head AND
the file tracked in head is related to the original file.
Note that the only difference between the original goal and the corrected
goal is the two extra conditions added at the end. The first condition is
relevant in a rename/delete conflict. If the file was deleted on the
HEAD side of the merge and an untracked file of the same name was added to
the working copy, then without that extra condition the untracked file
will be erroneously deleted. This changes <expression> to "renamed_stage
== 2 || !was_tracked(ren1_src)".
The second additional condition is relevant in two cases.
The first case the second condition can occur is when a file is deleted
and a completely different file is added with the same name. To my
knowledge, merge-recursive has no mechanism for detecting deleted-and-
replaced-by-different-file cases, so I am simply punting on this
possibility.
The second case for the second condition to occur is when there is a
rename/rename/add-source conflict. That is, when the original file was
renamed on both sides of history AND the original filename is being
re-used by some unrelated (but tracked) content. This case also presents
some additional difficulties for us since we cannot currently detect these
rename/rename/add-source conflicts; as long as the rename detection logic
"optimizes" by ignoring filenames that are present at both ends of the
diff, these conflicts will go unnoticed. However, rename/rename conflicts
are handled by an entirely separate codepath not being discussed here, so
this case is not relevant for the line of code under consideration.
In summary:
Change <expression> from "o->call_depth || renamed_stage == 2" to
"renamed_stage == 2 || !was_tracked(ren1_src)", in order to remove
unnecessary code and avoid deleting untracked files.
96 lines of explanation in the changelog to describe a one-line fix...
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:20:03 +00:00
|
|
|
test_expect_success "Does git preserve Gollum's precious artifact?" '
|
2011-08-12 05:19:34 +00:00
|
|
|
test_must_fail git merge -s recursive rename-the-ring &&
|
|
|
|
|
|
|
|
|
|
# Make sure git did not delete an untracked file
|
|
|
|
|
test -f ring
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:19:35 +00:00
|
|
|
# Testcase setup for rename/modify/add-source:
|
|
|
|
|
# Commit A: new file: a
|
|
|
|
|
# Commit B: modify a slightly
|
|
|
|
|
# Commit C: rename a->b, add completely different a
|
|
|
|
|
#
|
|
|
|
|
# We should be able to merge B & C cleanly
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/modify/add-source conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n6\n7\n" >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
echo 8 >>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
echo something completely different >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'rename/modify/add-source conflict resolvable' '
|
|
|
|
|
git checkout B^0 &&
|
|
|
|
|
|
|
|
|
|
git merge -s recursive C^0 &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse B:a) = $(git rev-parse b) &&
|
|
|
|
|
test $(git rev-parse C:a) = $(git rev-parse a)
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:19:36 +00:00
|
|
|
test_expect_success 'setup resolvable conflict missed if rename missed' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n" >a &&
|
|
|
|
|
echo foo >b &&
|
|
|
|
|
git add a b &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
echo "Completely different content" >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
echo 6 >>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'conflict caused if rename not detected' '
|
|
|
|
|
git checkout -q C^0 &&
|
|
|
|
|
git merge -s recursive B^0 &&
|
|
|
|
|
|
|
|
|
|
test 3 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
2012-04-11 11:24:01 +00:00
|
|
|
test_line_count = 6 c &&
|
2011-08-12 05:19:36 +00:00
|
|
|
test $(git rev-parse HEAD:a) = $(git rev-parse B:a) &&
|
|
|
|
|
test $(git rev-parse HEAD:b) = $(git rev-parse A:b)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup conflict resolved wrong if rename missed' '
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git clean -f &&
|
|
|
|
|
|
|
|
|
|
git checkout -b D A &&
|
|
|
|
|
echo 7 >>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
echo "Completely different content" >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m D &&
|
|
|
|
|
|
|
|
|
|
git checkout -b E A &&
|
|
|
|
|
git rm a &&
|
|
|
|
|
echo "Completely different content" >>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m E
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'missed conflict if rename not detected' '
|
|
|
|
|
git checkout -q E^0 &&
|
|
|
|
|
test_must_fail git merge -s recursive D^0
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:19:37 +00:00
|
|
|
# Tests for undetected rename/add-source causing a file to erroneously be
|
|
|
|
|
# deleted (and for mishandled rename/rename(1to1) causing the same issue).
|
|
|
|
|
#
|
|
|
|
|
# This test uses a rename/rename(1to1)+add-source conflict (1to1 means the
|
|
|
|
|
# same file is renamed on both sides to the same thing; it should trigger
|
|
|
|
|
# the 1to2 logic, which it would do if the add-source didn't cause issues
|
|
|
|
|
# for git's rename detection):
|
|
|
|
|
# Commit A: new file: a
|
|
|
|
|
# Commit B: rename a->b
|
|
|
|
|
# Commit C: rename a->b, add unrelated a
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup undetected rename/add-source causes data loss' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n" >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
echo foobar >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'detect rename/add-source and preserve all data' '
|
|
|
|
|
git checkout B^0 &&
|
|
|
|
|
|
|
|
|
|
git merge -s recursive C^0 &&
|
|
|
|
|
|
|
|
|
|
test 2 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test -f a &&
|
|
|
|
|
test -f b &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'detect rename/add-source and preserve all data, merge other way' '
|
|
|
|
|
git checkout C^0 &&
|
|
|
|
|
|
|
|
|
|
git merge -s recursive B^0 &&
|
|
|
|
|
|
|
|
|
|
test 2 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test -f a &&
|
|
|
|
|
test -f b &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
|
|
|
|
|
'
|
|
|
|
|
|
t6042: Add tests for content issues with modify/rename/directory conflicts
Add testcases that cover a variety of merge issues with files being
renamed and modified on different sides of history, when there are
directories possibly conflicting with the rename location.
Case 1:
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a non-conflicting
way but is renamed to the location of the new directory.
Case 2:
[Same as case 1, but there is also a content conflict. In detail:]
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a conflicting way
and it is renamed to the location of the new directory.
Case 3:
[Similar to case 1, but the "conflicting" directory is the directory
where the file original resided. In detail:]
On one side of history, a file is modified. On the other side of history,
the file is modified in a non-conflicting way, but the directory it was
under is removed and the file is renamed to the location of the directory
it used to reside in (i.e. 'sub/file' gets renamed to 'sub'). This is
flagged as a directory/rename conflict, but should be able to be resolved
since the directory can be cleanly removed by the merge.
One branch renames a file and makes a file where the directory the renamed
file used to be in, and the other branch updates the file in
place. Merging them should resolve it cleanly as long as the content level
change on the branches do not overlap and rename is detected, or should
leave conflict without losing information.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:38 +00:00
|
|
|
test_expect_success 'setup content merge + rename/directory conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n6\n" >file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
git tag base &&
|
|
|
|
|
|
|
|
|
|
git checkout -b right &&
|
|
|
|
|
echo 7 >>file &&
|
|
|
|
|
mkdir newfile &&
|
|
|
|
|
echo junk >newfile/realfile &&
|
|
|
|
|
git add file newfile/realfile &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m right &&
|
|
|
|
|
|
|
|
|
|
git checkout -b left-conflict base &&
|
|
|
|
|
echo 8 >>file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
git mv file newfile &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m left &&
|
|
|
|
|
|
|
|
|
|
git checkout -b left-clean base &&
|
|
|
|
|
echo 0 >newfile &&
|
|
|
|
|
cat file >>newfile &&
|
|
|
|
|
git add newfile &&
|
|
|
|
|
git rm file &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m left
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:20:06 +00:00
|
|
|
test_expect_success 'rename/directory conflict + clean content merge' '
|
t6042: Add tests for content issues with modify/rename/directory conflicts
Add testcases that cover a variety of merge issues with files being
renamed and modified on different sides of history, when there are
directories possibly conflicting with the rename location.
Case 1:
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a non-conflicting
way but is renamed to the location of the new directory.
Case 2:
[Same as case 1, but there is also a content conflict. In detail:]
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a conflicting way
and it is renamed to the location of the new directory.
Case 3:
[Similar to case 1, but the "conflicting" directory is the directory
where the file original resided. In detail:]
On one side of history, a file is modified. On the other side of history,
the file is modified in a non-conflicting way, but the directory it was
under is removed and the file is renamed to the location of the directory
it used to reside in (i.e. 'sub/file' gets renamed to 'sub'). This is
flagged as a directory/rename conflict, but should be able to be resolved
since the directory can be cleanly removed by the merge.
One branch renames a file and makes a file where the directory the renamed
file used to be in, and the other branch updates the file in
place. Merging them should resolve it cleanly as long as the content level
change on the branches do not overlap and rename is detected, or should
leave conflict without losing information.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:38 +00:00
|
|
|
git reset --hard &&
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
|
|
|
|
|
git checkout left-clean^0 &&
|
|
|
|
|
|
|
|
|
|
test_must_fail git merge -s recursive right^0 &&
|
|
|
|
|
|
|
|
|
|
test 2 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 1 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 1 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
echo 0 >expect &&
|
|
|
|
|
git cat-file -p base:file >>expect &&
|
|
|
|
|
echo 7 >>expect &&
|
|
|
|
|
test_cmp expect newfile~HEAD &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse :2:newfile) = $(git hash-object expect) &&
|
|
|
|
|
|
|
|
|
|
test -f newfile/realfile &&
|
|
|
|
|
test -f newfile~HEAD
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:20:09 +00:00
|
|
|
test_expect_success 'rename/directory conflict + content merge conflict' '
|
t6042: Add tests for content issues with modify/rename/directory conflicts
Add testcases that cover a variety of merge issues with files being
renamed and modified on different sides of history, when there are
directories possibly conflicting with the rename location.
Case 1:
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a non-conflicting
way but is renamed to the location of the new directory.
Case 2:
[Same as case 1, but there is also a content conflict. In detail:]
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a conflicting way
and it is renamed to the location of the new directory.
Case 3:
[Similar to case 1, but the "conflicting" directory is the directory
where the file original resided. In detail:]
On one side of history, a file is modified. On the other side of history,
the file is modified in a non-conflicting way, but the directory it was
under is removed and the file is renamed to the location of the directory
it used to reside in (i.e. 'sub/file' gets renamed to 'sub'). This is
flagged as a directory/rename conflict, but should be able to be resolved
since the directory can be cleanly removed by the merge.
One branch renames a file and makes a file where the directory the renamed
file used to be in, and the other branch updates the file in
place. Merging them should resolve it cleanly as long as the content level
change on the branches do not overlap and rename is detected, or should
leave conflict without losing information.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:38 +00:00
|
|
|
git reset --hard &&
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
|
|
|
|
|
git checkout left-conflict^0 &&
|
|
|
|
|
|
|
|
|
|
test_must_fail git merge -s recursive right^0 &&
|
|
|
|
|
|
|
|
|
|
test 4 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 3 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 1 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
git cat-file -p left-conflict:newfile >left &&
|
|
|
|
|
git cat-file -p base:file >base &&
|
|
|
|
|
git cat-file -p right:file >right &&
|
|
|
|
|
test_must_fail git merge-file \
|
|
|
|
|
-L "HEAD:newfile" \
|
|
|
|
|
-L "" \
|
|
|
|
|
-L "right^0:file" \
|
|
|
|
|
left base right &&
|
|
|
|
|
test_cmp left newfile~HEAD &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse :1:newfile) = $(git rev-parse base:file) &&
|
|
|
|
|
test $(git rev-parse :2:newfile) = $(git rev-parse left-conflict:newfile) &&
|
|
|
|
|
test $(git rev-parse :3:newfile) = $(git rev-parse right:file) &&
|
|
|
|
|
|
|
|
|
|
test -f newfile/realfile &&
|
|
|
|
|
test -f newfile~HEAD
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup content merge + rename/directory conflict w/ disappearing dir' '
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
mkdir sub &&
|
|
|
|
|
printf "1\n2\n3\n4\n5\n6\n" >sub/file &&
|
|
|
|
|
git add sub/file &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
git tag base &&
|
|
|
|
|
|
|
|
|
|
git checkout -b right &&
|
|
|
|
|
echo 7 >>sub/file &&
|
|
|
|
|
git add sub/file &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m right &&
|
|
|
|
|
|
|
|
|
|
git checkout -b left base &&
|
|
|
|
|
echo 0 >newfile &&
|
|
|
|
|
cat sub/file >>newfile &&
|
|
|
|
|
git rm sub/file &&
|
|
|
|
|
mv newfile sub &&
|
|
|
|
|
git add sub &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m left
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'disappearing dir in rename/directory conflict handled' '
|
|
|
|
|
git reset --hard &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
|
|
|
|
|
git checkout left^0 &&
|
|
|
|
|
|
|
|
|
|
git merge -s recursive right^0 &&
|
|
|
|
|
|
|
|
|
|
test 1 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
echo 0 >expect &&
|
|
|
|
|
git cat-file -p base:sub/file >>expect &&
|
|
|
|
|
echo 7 >>expect &&
|
|
|
|
|
test_cmp expect sub &&
|
|
|
|
|
|
|
|
|
|
test -f sub
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:19:39 +00:00
|
|
|
# Test for all kinds of things that can go wrong with rename/rename (2to1):
|
|
|
|
|
# Commit A: new files: a & b
|
|
|
|
|
# Commit B: rename a->c, modify b
|
|
|
|
|
# Commit C: rename b->c, modify a
|
|
|
|
|
#
|
|
|
|
|
# Merging of B & C should NOT be clean. Questions:
|
|
|
|
|
# * Both a & b should be removed by the merge; are they?
|
|
|
|
|
# * The two c's should contain modifications to a & b; do they?
|
|
|
|
|
# * The index should contain two files, both for c; does it?
|
|
|
|
|
# * The working copy should have two files, both of form c~<unique>; does it?
|
|
|
|
|
# * Nothing else should be present. Is anything?
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/rename (2to1) + modify/modify' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n" >a &&
|
|
|
|
|
printf "5\n4\n3\n2\n1\n" >b &&
|
|
|
|
|
git add a b &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
echo 0 >>b &&
|
|
|
|
|
git add b &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv b c &&
|
|
|
|
|
echo 6 >>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
merge-recursive: Consider modifications in rename/rename(2to1) conflicts
Our previous conflict resolution for renaming two different files to the
same name ignored the fact that each of those files may have modifications
from both sides of history to consider. We need to do a three-way merge
for each of those files, and then handle the conflict of both sets of
merged contents trying to be recorded with the same name.
It is important to note that this changes our strategy in the recursive
case. After doing a three-way content merge of each of the files
involved, we still are faced with the fact that we are trying to put both
of the results (including conflict markers) into the same path. We could
do another two-way merge, but I think that becomes confusing. Also,
taking a hint from the modify/delete and rename/delete cases we handled
earlier, a more useful "common ground" would be to keep the three-way
content merge but record it with the original filename. The renames can
still be detected, we just allow it to be done in the o->call_depth=0
case. This seems to result in simpler & easier to understand merge
conflicts as well, as evidenced by some of the changes needed in our
testsuite in t6036. (However, it should be noted that this change will
cause problems those renames also occur along with a file being added
whose name matches the source of the rename. Since git currently cannot
detect rename/add-source situations, though, this codepath is not
currently used for those cases anyway.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:20:18 +00:00
|
|
|
test_expect_success 'handle rename/rename (2to1) conflict correctly' '
|
2011-08-12 05:19:39 +00:00
|
|
|
git checkout B^0 &&
|
|
|
|
|
|
|
|
|
|
test_must_fail git merge -s recursive C^0 >out &&
|
2012-07-25 14:53:13 +00:00
|
|
|
test_i18ngrep "CONFLICT (rename/rename)" out &&
|
2011-08-12 05:19:39 +00:00
|
|
|
|
|
|
|
|
test 2 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u c | wc -l) &&
|
|
|
|
|
test 3 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test ! -f a &&
|
|
|
|
|
test ! -f b &&
|
|
|
|
|
test -f c~HEAD &&
|
|
|
|
|
test -f c~C^0 &&
|
|
|
|
|
|
|
|
|
|
test $(git hash-object c~HEAD) = $(git rev-parse C:a) &&
|
|
|
|
|
test $(git hash-object c~C^0) = $(git rev-parse B:b)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
# Testcase setup for simple rename/rename (1to2) conflict:
|
|
|
|
|
# Commit A: new file: a
|
|
|
|
|
# Commit B: rename a->b
|
|
|
|
|
# Commit C: rename a->c
|
|
|
|
|
test_expect_success 'setup simple rename/rename (1to2) conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
echo stuff >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'merge has correct working tree contents' '
|
|
|
|
|
git checkout C^0 &&
|
|
|
|
|
|
|
|
|
|
test_must_fail git merge -s recursive B^0 &&
|
|
|
|
|
|
|
|
|
|
test 3 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 3 -eq $(git ls-files -u | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse :1:a) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse :3:b) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse :2:c) = $(git rev-parse A:a) &&
|
|
|
|
|
|
|
|
|
|
test ! -f a &&
|
|
|
|
|
test $(git hash-object b) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git hash-object c) = $(git rev-parse A:a)
|
|
|
|
|
'
|
|
|
|
|
|
t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
Add testcases that cover three failures with current git merge, all
involving renaming one file on both sides of history:
Case 1:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. Adding a new file on one of those
sides of history whose name happens to match the rename source should not
cause the merge to suddenly succeed.
Case 2:
If a single file is renamed on both sides of history but renamed
identically, there should not be a conflict. This works fine. However,
if one of those sides also added a new file that happened to match the
rename source, then that file should be left alone. Currently, the
rename/rename conflict handling causes that new file to become untracked.
Case 3:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. This works currently. However,
if those renames also involve rename/add conflicts (i.e. there are new
files on one side of history that match the destination of the rename of
the other side of history), then the resulting conflict should be recorded
in the index, showing that there were multiple files with a given filename.
Currently, git silently discards one of file versions.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:40 +00:00
|
|
|
# Testcase setup for rename/rename(1to2)/add-source conflict:
|
|
|
|
|
# Commit A: new file: a
|
|
|
|
|
# Commit B: rename a->b
|
|
|
|
|
# Commit C: rename a->c, add completely different a
|
|
|
|
|
#
|
|
|
|
|
# Merging of B & C should NOT be clean; there's a rename/rename conflict
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/rename(1to2)/add-source conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
printf "1\n2\n3\n4\n5\n6\n7\n" >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m A &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
git commit -m B &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
echo something completely different >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
git commit -m C
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'detect conflict with rename/rename(1to2)/add-source merge' '
|
|
|
|
|
git checkout B^0 &&
|
|
|
|
|
|
|
|
|
|
test_must_fail git merge -s recursive C^0 &&
|
|
|
|
|
|
|
|
|
|
test 4 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse 3:a) = $(git rev-parse C:a) &&
|
|
|
|
|
test $(git rev-parse 1:a) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse 2:b) = $(git rev-parse B:b) &&
|
|
|
|
|
test $(git rev-parse 3:c) = $(git rev-parse C:c) &&
|
|
|
|
|
|
|
|
|
|
test -f a &&
|
|
|
|
|
test -f b &&
|
|
|
|
|
test -f c
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/rename(1to2)/add-source resolvable conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
>a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m one &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
echo important-info >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m two
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_failure 'rename/rename/add-source still tracks new a file' '
|
|
|
|
|
git checkout C^0 &&
|
|
|
|
|
git merge -s recursive B^0 &&
|
|
|
|
|
|
|
|
|
|
test 2 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 0 -eq $(git ls-files -o | wc -l) &&
|
|
|
|
|
|
|
|
|
|
test $(git rev-parse HEAD:a) = $(git rev-parse C:a) &&
|
|
|
|
|
test $(git rev-parse HEAD:b) = $(git rev-parse A:a)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup rename/rename(1to2)/add-dest conflict' '
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
git clean -fdqx &&
|
|
|
|
|
rm -rf .git &&
|
|
|
|
|
git init &&
|
|
|
|
|
|
|
|
|
|
echo stuff >a &&
|
|
|
|
|
git add a &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
git tag A &&
|
|
|
|
|
|
|
|
|
|
git checkout -b B A &&
|
|
|
|
|
git mv a b &&
|
|
|
|
|
echo precious-data >c &&
|
|
|
|
|
git add c &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m one &&
|
|
|
|
|
|
|
|
|
|
git checkout -b C A &&
|
|
|
|
|
git mv a c &&
|
|
|
|
|
echo important-info >b &&
|
|
|
|
|
git add b &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m two
|
|
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:20:21 +00:00
|
|
|
test_expect_success 'rename/rename/add-dest merge still knows about conflicting file versions' '
|
t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
Add testcases that cover three failures with current git merge, all
involving renaming one file on both sides of history:
Case 1:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. Adding a new file on one of those
sides of history whose name happens to match the rename source should not
cause the merge to suddenly succeed.
Case 2:
If a single file is renamed on both sides of history but renamed
identically, there should not be a conflict. This works fine. However,
if one of those sides also added a new file that happened to match the
rename source, then that file should be left alone. Currently, the
rename/rename conflict handling causes that new file to become untracked.
Case 3:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. This works currently. However,
if those renames also involve rename/add conflicts (i.e. there are new
files on one side of history that match the destination of the rename of
the other side of history), then the resulting conflict should be recorded
in the index, showing that there were multiple files with a given filename.
Currently, git silently discards one of file versions.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:40 +00:00
|
|
|
git checkout C^0 &&
|
|
|
|
|
test_must_fail git merge -s recursive B^0 &&
|
|
|
|
|
|
|
|
|
|
test 5 -eq $(git ls-files -s | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u b | wc -l) &&
|
|
|
|
|
test 2 -eq $(git ls-files -u c | wc -l) &&
|
2011-08-12 05:20:22 +00:00
|
|
|
test 4 -eq $(git ls-files -o | wc -l) &&
|
t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
Add testcases that cover three failures with current git merge, all
involving renaming one file on both sides of history:
Case 1:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. Adding a new file on one of those
sides of history whose name happens to match the rename source should not
cause the merge to suddenly succeed.
Case 2:
If a single file is renamed on both sides of history but renamed
identically, there should not be a conflict. This works fine. However,
if one of those sides also added a new file that happened to match the
rename source, then that file should be left alone. Currently, the
rename/rename conflict handling causes that new file to become untracked.
Case 3:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. This works currently. However,
if those renames also involve rename/add conflicts (i.e. there are new
files on one side of history that match the destination of the rename of
the other side of history), then the resulting conflict should be recorded
in the index, showing that there were multiple files with a given filename.
Currently, git silently discards one of file versions.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:40 +00:00
|
|
|
|
|
|
|
|
test $(git rev-parse :1:a) = $(git rev-parse A:a) &&
|
|
|
|
|
test $(git rev-parse :2:b) = $(git rev-parse C:b) &&
|
|
|
|
|
test $(git rev-parse :3:b) = $(git rev-parse B:b) &&
|
|
|
|
|
test $(git rev-parse :2:c) = $(git rev-parse C:c) &&
|
2011-08-12 05:20:22 +00:00
|
|
|
test $(git rev-parse :3:c) = $(git rev-parse B:c) &&
|
|
|
|
|
|
|
|
|
|
test $(git hash-object c~HEAD) = $(git rev-parse C:c) &&
|
|
|
|
|
test $(git hash-object c~B\^0) = $(git rev-parse B:c) &&
|
|
|
|
|
test $(git hash-object b~HEAD) = $(git rev-parse C:b) &&
|
|
|
|
|
test $(git hash-object b~B\^0) = $(git rev-parse B:b) &&
|
|
|
|
|
|
|
|
|
|
test ! -f b &&
|
|
|
|
|
test ! -f c
|
t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
Add testcases that cover three failures with current git merge, all
involving renaming one file on both sides of history:
Case 1:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. Adding a new file on one of those
sides of history whose name happens to match the rename source should not
cause the merge to suddenly succeed.
Case 2:
If a single file is renamed on both sides of history but renamed
identically, there should not be a conflict. This works fine. However,
if one of those sides also added a new file that happened to match the
rename source, then that file should be left alone. Currently, the
rename/rename conflict handling causes that new file to become untracked.
Case 3:
If a single file is renamed to two different filenames on different sides
of history, there should be a conflict. This works currently. However,
if those renames also involve rename/add conflicts (i.e. there are new
files on one side of history that match the destination of the rename of
the other side of history), then the resulting conflict should be recorded
in the index, showing that there were multiple files with a given filename.
Currently, git silently discards one of file versions.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-12 05:19:40 +00:00
|
|
|
'
|
|
|
|
|
|
2011-08-12 05:19:34 +00:00
|
|
|
test_done
|