git-commit-vandalism/t/t6042-merge-rename-corner-cases.sh

697 lines
15 KiB
Bash
Raw Normal View History

#!/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' '
test_create_repo rename-delete-untracked &&
(
cd rename-delete-untracked &&
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 07:20:03 +02:00
test_expect_success "Does git preserve Gollum's precious artifact?" '
(
cd rename-delete-untracked &&
test_must_fail git merge -s recursive rename-the-ring &&
# Make sure git did not delete an untracked file
test_path_is_file ring
)
'
# 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' '
test_create_repo rename-modify-add-source &&
(
cd rename-modify-add-source &&
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' '
(
cd rename-modify-add-source &&
git checkout B^0 &&
git merge -s recursive C^0 &&
git rev-parse >expect \
B:a C:a &&
git rev-parse >actual \
b c &&
test_cmp expect actual
)
'
test_expect_success 'setup resolvable conflict missed if rename missed' '
test_create_repo break-detection-1 &&
(
cd break-detection-1 &&
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' '
(
cd break-detection-1 &&
git checkout -q C^0 &&
git merge -s recursive B^0 &&
git ls-files -s >out &&
test_line_count = 3 out &&
git ls-files -u >out &&
test_line_count = 0 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
test_line_count = 6 c &&
git rev-parse >expect \
B:a A:b &&
git rev-parse >actual \
:0:a :0:b &&
test_cmp expect actual
)
'
test_expect_success 'setup conflict resolved wrong if rename missed' '
test_create_repo break-detection-2 &&
(
cd break-detection-2 &&
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 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' '
(
cd break-detection-2 &&
git checkout -q E^0 &&
test_must_fail git merge -s recursive D^0
)
'
# 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' '
test_create_repo break-detection-3 &&
(
cd break-detection-3 &&
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' '
(
cd break-detection-3 &&
git checkout B^0 &&
git merge -s recursive C^0 &&
git ls-files -s >out &&
test_line_count = 2 out &&
git ls-files -u >out &&
test_line_count = 2 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
test_path_is_file a &&
test_path_is_file b &&
git rev-parse >expect \
A:a C:a &&
git rev-parse >actual \
:0:b :0:a &&
test_cmp expect actual
)
'
test_expect_failure 'detect rename/add-source and preserve all data, merge other way' '
(
cd break-detection-3 &&
git checkout C^0 &&
git merge -s recursive B^0 &&
git ls-files -s >out &&
test_line_count = 2 out &&
git ls-files -u >out &&
test_line_count = 2 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
test_path_is_file a &&
test_path_is_file b &&
git rev-parse >expect \
A:a C:a &&
git rev-parse >actual \
:0:b :0:a &&
test_cmp expect actual
)
'
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 07:19:38 +02:00
test_expect_success 'setup content merge + rename/directory conflict' '
test_create_repo rename-directory-1 &&
(
cd rename-directory-1 &&
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
)
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 07:19:38 +02:00
'
test_expect_success 'rename/directory conflict + clean content merge' '
(
cd rename-directory-1 &&
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 07:19:38 +02:00
git checkout left-clean^0 &&
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 07:19:38 +02:00
test_must_fail git merge -s recursive right^0 &&
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 07:19:38 +02:00
git ls-files -s >out &&
test_line_count = 2 out &&
git ls-files -u >out &&
test_line_count = 1 out &&
git ls-files -o >out &&
test_line_count = 2 out &&
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 07:19:38 +02:00
echo 0 >expect &&
git cat-file -p base:file >>expect &&
echo 7 >>expect &&
test_cmp expect newfile~HEAD &&
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 07:19:38 +02:00
test $(git rev-parse :2:newfile) = $(git hash-object expect) &&
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 07:19:38 +02:00
test_path_is_file newfile/realfile &&
test_path_is_file newfile~HEAD
)
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 07:19:38 +02:00
'
test_expect_success 'rename/directory conflict + content merge conflict' '
(
cd rename-directory-1 &&
git reset --hard &&
git reset --hard &&
git clean -fdqx &&
git checkout left-conflict^0 &&
test_must_fail git merge -s recursive right^0 &&
git ls-files -s >out &&
test_line_count = 4 out &&
git ls-files -u >out &&
test_line_count = 3 out &&
git ls-files -o >out &&
test_line_count = 2 out &&
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 &&
git rev-parse >expect \
base:file left-conflict:newfile right:file &&
git rev-parse >actual \
:1:newfile :2:newfile :3:newfile &&
test_cmp expect actual
test_path_is_file newfile/realfile &&
test_path_is_file newfile~HEAD
)
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 07:19:38 +02:00
'
test_expect_success 'setup content merge + rename/directory conflict w/ disappearing dir' '
test_create_repo rename-directory-2 &&
(
cd rename-directory-2 &&
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
)
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 07:19:38 +02:00
'
test_expect_success 'disappearing dir in rename/directory conflict handled' '
(
cd rename-directory-2 &&
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 07:19:38 +02:00
git checkout left^0 &&
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 07:19:38 +02:00
git merge -s recursive right^0 &&
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 07:19:38 +02:00
git ls-files -s >out &&
test_line_count = 1 out &&
git ls-files -u >out &&
test_line_count = 0 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
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 07:19:38 +02:00
echo 0 >expect &&
git cat-file -p base:sub/file >>expect &&
echo 7 >>expect &&
test_cmp expect sub &&
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 07:19:38 +02:00
test_path_is_file sub
)
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 07:19:38 +02: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' '
test_create_repo rename-rename-2to1 &&
(
cd rename-rename-2to1 &&
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 07:20:18 +02:00
test_expect_success 'handle rename/rename (2to1) conflict correctly' '
(
cd rename-rename-2to1 &&
git checkout B^0 &&
test_must_fail git merge -s recursive C^0 >out &&
test_i18ngrep "CONFLICT (rename/rename)" out &&
git ls-files -s >out &&
test_line_count = 2 out &&
git ls-files -u >out &&
test_line_count = 2 out &&
git ls-files -u c >out &&
test_line_count = 2 out &&
git ls-files -o >out &&
test_line_count = 3 out &&
test_path_is_missing a &&
test_path_is_missing b &&
test_path_is_file c~HEAD &&
test_path_is_file c~C^0 &&
git rev-parse >expect \
C:a B:b &&
git hash-object >actual \
c~HEAD c~C^0 &&
test_cmp expect actual
)
'
# 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' '
test_create_repo rename-rename-1to2 &&
(
cd rename-rename-1to2 &&
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' '
(
cd rename-rename-1to2 &&
git checkout C^0 &&
test_must_fail git merge -s recursive B^0 &&
git ls-files -s >out &&
test_line_count = 3 out &&
git ls-files -u >out &&
test_line_count = 3 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
test_path_is_missing a &&
git rev-parse >expect \
A:a A:a A:a \
A:a A:a &&
git rev-parse >actual \
:1:a :3:b :2:c &&
git hash-object >>actual \
b c &&
test_cmp expect actual
)
'
# 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' '
test_create_repo rename-rename-1to2-add-source-1 &&
(
cd rename-rename-1to2-add-source-1 &&
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' '
(
cd rename-rename-1to2-add-source-1 &&
git checkout B^0 &&
test_must_fail git merge -s recursive C^0 &&
git ls-files -s >out &&
test_line_count = 4 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
git rev-parse >expect \
C:a A:a B:b C:C &&
git rev-parse >actual \
:3:a :1:a :2:b :3:c &&
test_cmp expect actual
test_path_is_file a &&
test_path_is_file b &&
test_path_is_file c
)
'
test_expect_success 'setup rename/rename(1to2)/add-source resolvable conflict' '
test_create_repo rename-rename-1to2-add-source-2 &&
(
cd rename-rename-1to2-add-source-2 &&
>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' '
(
cd rename-rename-1to2-add-source-2 &&
git checkout C^0 &&
git merge -s recursive B^0 &&
git ls-files -s >out &&
test_line_count = 2 out &&
git ls-files -o >out &&
test_line_count = 1 out &&
git rev-parse >expect \
C:a A:a &&
git rev-parse >actual \
:0:a :0:b &&
test_cmp expect actual
)
'
test_expect_success 'setup rename/rename(1to2)/add-dest conflict' '
test_create_repo rename-rename-1to2-add-dest &&
(
cd rename-rename-1to2-add-dest &&
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
)
'
test_expect_success 'rename/rename/add-dest merge still knows about conflicting file versions' '
(
cd rename-rename-1to2-add-dest &&
git checkout C^0 &&
test_must_fail git merge -s recursive B^0 &&
git ls-files -s >out &&
test_line_count = 5 out &&
git ls-files -u b >out &&
test_line_count = 2 out &&
git ls-files -u c >out &&
test_line_count = 2 out &&
git ls-files -o >out &&
test_line_count = 5 out &&
git rev-parse >expect \
A:a C:b B:b C:c B:c &&
git rev-parse >actual \
:1:a :2:b :3:b :2:c :3:c &&
test_cmp expect actual
git rev-parse >expect \
C:c B:c C:b B:b &&
git hash-object >actual \
c~HEAD c~B\^0 b~HEAD b~B\^0 &&
test_cmp expect actual
test_path_is_missing b &&
test_path_is_missing c
)
'
test_done