mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-12-13 20:06:31 +08:00
Code Issues Packages Projects Releases Wiki Activity
feea6946a5
git/t/t6044-merge-unrelated-index-changes.sh

217 lines
4.5 KiB
Bash
Raw Normal View History

t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
#!/bin/sh
test_description="merges with unrelated index changes"
. ./test-lib.sh
# Testcase for some simple merges
# A
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
# o-------o B
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
# \
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
# \-----o C
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
# \
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
# \---o D
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
# \
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
# \-o E
# \
# o F
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
# Commit A: some file a
# Commit B: adds file b, modifies end of a
# Commit C: adds file c
# Commit D: adds file d, modifies beginning of a
# Commit E: renames a->subdir/a, adds subdir/e
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
# Commit F: empty commit
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
test_expect_success 'setup trivial merges' '
t6044: replace seq by test_seq seq is not available everywhere. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 13:51:39 +08:00
test_seq 1 10 >a &&
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
git add a &&
test_tick && git commit -m A &&
git branch A &&
git branch B &&
git branch C &&
git branch D &&
git branch E &&
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
git branch F &&
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
git checkout B &&
echo b >b &&
echo 11 >>a &&
git add a b &&
test_tick && git commit -m B &&
git checkout C &&
echo c >c &&
git add c &&
test_tick && git commit -m C &&
git checkout D &&
t6044: replace seq by test_seq seq is not available everywhere. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18 13:51:39 +08:00
test_seq 2 10 >a &&
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
echo d >d &&
git add a d &&
test_tick && git commit -m D &&
git checkout E &&
mkdir subdir &&
git mv a subdir/a &&
echo e >subdir/e &&
git add subdir &&
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
test_tick && git commit -m E &&
git checkout F &&
test_tick && git commit --allow-empty -m F
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'ff update' '
git reset --hard &&
git checkout A^0 &&
touch random_file && git add random_file &&
git merge E^0 &&
test_must_fail git rev-parse HEAD:random_file &&
test "$(git diff --name-only --cached E)" = "random_file"
'
test_expect_success 'ff update, important file modified' '
git reset --hard &&
git checkout A^0 &&
mkdir subdir &&
touch subdir/e &&
git add subdir/e &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge E^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'resolve, trivial' '
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s resolve C^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'resolve, non-trivial' '
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s resolve D^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'recursive' '
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s recursive C^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
merge-recursive: make sure when we say we abort that we actually abort In commit 65170c07d4 ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21), it was noted that there was a special case when merge-recursive didn't rely on unpack_trees() to enforce the index == HEAD requirement, and thus that it needed to do that enforcement itself. Unfortunately, it returned the wrong exit status, signalling that the merge completed but had conflicts, rather than that it was aborted. Fix the return code, and while we're at it, change the error message to match what unpack_trees() would have printed. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:59 +08:00
test_expect_success 'recursive, when merge branch matches merge base' '
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s recursive F^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: recursive can silently incorporate dirty changes in a merge The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22 03:19:05 +08:00
'
merge-recursive: fix assumption that head tree being merged is HEAD `git merge-recursive` does a three-way merge between user-specified trees base, head, and remote. Since the user is allowed to specify head, we can not necesarily assume that head == HEAD. Modify index_has_changes() to take an extra argument specifying the tree to compare against. If NULL, it will compare to HEAD. We then use this from merge-recursive to make sure we compare to the user-specified head. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:00 +08:00
test_expect_success 'merge-recursive, when index==head but head!=HEAD' '
t6044: add a testcase for index matching head, when head doesn't match HEAD The `git merge-recursive` command allows the user to directly specify three commits to merge -- base, head, and remote. (More than three can be specified in the case of multiple merge bases.) Note that since the user is allowed to specify head, it need not match HEAD. Virtually every test and script in the current git.git codebase calls `git merge-recursive` with head=HEAD, and likely external callers do as well, which is why this has gone unnoticed. There is one notable counter-example: git-stash.sh. However, git-stash called `git merge-recursive` with an index that matches the expected merge result, which happens to be a currently allowed exception to the "index must match head" rule, so this never triggered an error previously. Since we would like to tighten up the "index must match head" rule, we need to make sure we are comparing to the correct head. Add a testcase that demonstrates the failure when we check the wrong HEAD. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:58 +08:00
git reset --hard &&
git checkout C^0 &&
# Make index match B
git diff C B -- | git apply --cached &&
# Merge B & F, with B as "head"
git merge-recursive A -- B F > out &&
test_i18ngrep "Already up to date" out
'
merge-recursive: enforce rule that index matches head before merging builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to date!" merge. unpack-trees.c does not actually enforce this requirement, though. It allows for a pair of exceptions, in cases which it refers to as #14(ALT) and #2ALT. Documentation/technical/trivial-merge.txt can be consulted for the precise meanings of the various case numbers and their meanings for unpack-trees.c, but we have a high-level description of the intent behind these two exceptions in a combined and summarized form in Documentation/git-merge.txt: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) While this high-level description does describe conditions under which it would be safe to allow the index to diverge from HEAD, it does not match what is actually implemented. In particular, unpack-trees.c has no knowledge of renames, and these two exceptions were written assuming that no renames take place. Once renames get into the mix, it is no longer safe to allow the index to not match for #2ALT. We could modify unpack-trees to only allow #14(ALT) as an exception, but that would be more strict than required for the resolve strategy (since the resolve strategy doesn't handle renames at all). Therefore, unpack_trees.c seems like the wrong place to fix this. Further, if someone fixes the combination of break and rename detection and modifies merge-recursive to take advantage of the combination, then it will also no longer be safe to allow the index to not match for #14(ALT) when the recursive strategy is in use. Therefore, leaving one of the exceptions in place with the recursive merge strategy feels like we are just leaving a latent bug in the code for folks in the future to stumble across. It may be possible to fix both unpack-trees and merge-recursive in a way that implements the exception as stated in Documentation/git-merge.txt, but it would be somewhat complex, possibly also buggy at first, and ultimately, not all that valuable. Instead, just enforce the requirement stated in builtin/merge.c; error out if the index does not match the HEAD commit, just like the 'ours' and 'octopus' strategies do. Some testcase fixups were in order: t7611: had many tests designed to show that `git merge --abort` could not always restore the index and working tree to the state they were in before the merge started. The tests that were associated with having changes in the index before the merge started are no longer applicable, so they have been removed. t7504: had a few tests that had stray staged changes that were not actually part of the test under consideration t6044: We no longer expect stray staged changes to sometimes result in the merge continuing. Also, fix a case where a merge didn't abort but should have. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:02 +08:00
test_expect_success 'recursive, when file has staged changes not matching HEAD nor what a merge would give' '
t6044: add more testcases with staged changes before a merge is invoked According to Documentation/git-merge.txt, ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Add some tests showing that this exception, while it does accurately state what would be a safe condition under which we could allow the merge to proceed, is not what is actually implemented. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:01 +08:00
git reset --hard &&
git checkout B^0 &&
mkdir subdir &&
test_seq 1 10 >subdir/a &&
git add subdir/a &&
merge-recursive: enforce rule that index matches head before merging builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to date!" merge. unpack-trees.c does not actually enforce this requirement, though. It allows for a pair of exceptions, in cases which it refers to as #14(ALT) and #2ALT. Documentation/technical/trivial-merge.txt can be consulted for the precise meanings of the various case numbers and their meanings for unpack-trees.c, but we have a high-level description of the intent behind these two exceptions in a combined and summarized form in Documentation/git-merge.txt: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) While this high-level description does describe conditions under which it would be safe to allow the index to diverge from HEAD, it does not match what is actually implemented. In particular, unpack-trees.c has no knowledge of renames, and these two exceptions were written assuming that no renames take place. Once renames get into the mix, it is no longer safe to allow the index to not match for #2ALT. We could modify unpack-trees to only allow #14(ALT) as an exception, but that would be more strict than required for the resolve strategy (since the resolve strategy doesn't handle renames at all). Therefore, unpack_trees.c seems like the wrong place to fix this. Further, if someone fixes the combination of break and rename detection and modifies merge-recursive to take advantage of the combination, then it will also no longer be safe to allow the index to not match for #14(ALT) when the recursive strategy is in use. Therefore, leaving one of the exceptions in place with the recursive merge strategy feels like we are just leaving a latent bug in the code for folks in the future to stumble across. It may be possible to fix both unpack-trees and merge-recursive in a way that implements the exception as stated in Documentation/git-merge.txt, but it would be somewhat complex, possibly also buggy at first, and ultimately, not all that valuable. Instead, just enforce the requirement stated in builtin/merge.c; error out if the index does not match the HEAD commit, just like the 'ours' and 'octopus' strategies do. Some testcase fixups were in order: t7611: had many tests designed to show that `git merge --abort` could not always restore the index and working tree to the state they were in before the merge started. The tests that were associated with having changes in the index before the merge started are no longer applicable, so they have been removed. t7504: had a few tests that had stray staged changes that were not actually part of the test under consideration t6044: We no longer expect stray staged changes to sometimes result in the merge continuing. Also, fix a case where a merge didn't abort but should have. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:02 +08:00
# We have staged changes; merge should error out
test_must_fail git merge -s recursive E^0 2>err &&
test_i18ngrep "changes to the following files would be overwritten" err
t6044: add more testcases with staged changes before a merge is invoked According to Documentation/git-merge.txt, ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Add some tests showing that this exception, while it does accurately state what would be a safe condition under which we could allow the merge to proceed, is not what is actually implemented. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:01 +08:00
'
merge-recursive: enforce rule that index matches head before merging builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to date!" merge. unpack-trees.c does not actually enforce this requirement, though. It allows for a pair of exceptions, in cases which it refers to as #14(ALT) and #2ALT. Documentation/technical/trivial-merge.txt can be consulted for the precise meanings of the various case numbers and their meanings for unpack-trees.c, but we have a high-level description of the intent behind these two exceptions in a combined and summarized form in Documentation/git-merge.txt: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) While this high-level description does describe conditions under which it would be safe to allow the index to diverge from HEAD, it does not match what is actually implemented. In particular, unpack-trees.c has no knowledge of renames, and these two exceptions were written assuming that no renames take place. Once renames get into the mix, it is no longer safe to allow the index to not match for #2ALT. We could modify unpack-trees to only allow #14(ALT) as an exception, but that would be more strict than required for the resolve strategy (since the resolve strategy doesn't handle renames at all). Therefore, unpack_trees.c seems like the wrong place to fix this. Further, if someone fixes the combination of break and rename detection and modifies merge-recursive to take advantage of the combination, then it will also no longer be safe to allow the index to not match for #14(ALT) when the recursive strategy is in use. Therefore, leaving one of the exceptions in place with the recursive merge strategy feels like we are just leaving a latent bug in the code for folks in the future to stumble across. It may be possible to fix both unpack-trees and merge-recursive in a way that implements the exception as stated in Documentation/git-merge.txt, but it would be somewhat complex, possibly also buggy at first, and ultimately, not all that valuable. Instead, just enforce the requirement stated in builtin/merge.c; error out if the index does not match the HEAD commit, just like the 'ours' and 'octopus' strategies do. Some testcase fixups were in order: t7611: had many tests designed to show that `git merge --abort` could not always restore the index and working tree to the state they were in before the merge started. The tests that were associated with having changes in the index before the merge started are no longer applicable, so they have been removed. t7504: had a few tests that had stray staged changes that were not actually part of the test under consideration t6044: We no longer expect stray staged changes to sometimes result in the merge continuing. Also, fix a case where a merge didn't abort but should have. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:02 +08:00
test_expect_success 'recursive, when file has staged changes matching what a merge would give' '
t6044: add more testcases with staged changes before a merge is invoked According to Documentation/git-merge.txt, ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Add some tests showing that this exception, while it does accurately state what would be a safe condition under which we could allow the merge to proceed, is not what is actually implemented. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:01 +08:00
git reset --hard &&
git checkout B^0 &&
mkdir subdir &&
test_seq 1 11 >subdir/a &&
git add subdir/a &&
merge-recursive: enforce rule that index matches head before merging builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to date!" merge. unpack-trees.c does not actually enforce this requirement, though. It allows for a pair of exceptions, in cases which it refers to as #14(ALT) and #2ALT. Documentation/technical/trivial-merge.txt can be consulted for the precise meanings of the various case numbers and their meanings for unpack-trees.c, but we have a high-level description of the intent behind these two exceptions in a combined and summarized form in Documentation/git-merge.txt: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) While this high-level description does describe conditions under which it would be safe to allow the index to diverge from HEAD, it does not match what is actually implemented. In particular, unpack-trees.c has no knowledge of renames, and these two exceptions were written assuming that no renames take place. Once renames get into the mix, it is no longer safe to allow the index to not match for #2ALT. We could modify unpack-trees to only allow #14(ALT) as an exception, but that would be more strict than required for the resolve strategy (since the resolve strategy doesn't handle renames at all). Therefore, unpack_trees.c seems like the wrong place to fix this. Further, if someone fixes the combination of break and rename detection and modifies merge-recursive to take advantage of the combination, then it will also no longer be safe to allow the index to not match for #14(ALT) when the recursive strategy is in use. Therefore, leaving one of the exceptions in place with the recursive merge strategy feels like we are just leaving a latent bug in the code for folks in the future to stumble across. It may be possible to fix both unpack-trees and merge-recursive in a way that implements the exception as stated in Documentation/git-merge.txt, but it would be somewhat complex, possibly also buggy at first, and ultimately, not all that valuable. Instead, just enforce the requirement stated in builtin/merge.c; error out if the index does not match the HEAD commit, just like the 'ours' and 'octopus' strategies do. Some testcase fixups were in order: t7611: had many tests designed to show that `git merge --abort` could not always restore the index and working tree to the state they were in before the merge started. The tests that were associated with having changes in the index before the merge started are no longer applicable, so they have been removed. t7504: had a few tests that had stray staged changes that were not actually part of the test under consideration t6044: We no longer expect stray staged changes to sometimes result in the merge continuing. Also, fix a case where a merge didn't abort but should have. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:02 +08:00
# We have staged changes; merge should error out
test_must_fail git merge -s recursive E^0 2>err &&
test_i18ngrep "changes to the following files would be overwritten" err
t6044: add more testcases with staged changes before a merge is invoked According to Documentation/git-merge.txt, ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Add some tests showing that this exception, while it does accurately state what would be a safe condition under which we could allow the merge to proceed, is not what is actually implemented. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:25:01 +08:00
'
merge-octopus: abort if index does not match HEAD Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:38 +08:00
test_expect_success 'octopus, unrelated file touched' '
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge C^0 D^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
merge-octopus: abort if index does not match HEAD Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:38 +08:00
test_expect_success 'octopus, related file removed' '
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
git reset --hard &&
git checkout B^0 &&
git rm b &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge C^0 D^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
merge-octopus: abort if index does not match HEAD Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:38 +08:00
test_expect_success 'octopus, related file modified' '
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
git reset --hard &&
git checkout B^0 &&
echo 12 >>a && git add a &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge C^0 D^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'ours' '
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s ours C^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_expect_success 'subtree' '
git reset --hard &&
git checkout B^0 &&
touch random_file && git add random_file &&
t6044: verify that merges expected to abort actually abort t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted, i.e. that .git/MERGE_HEAD is not present. This changes one of the tests from expect_success to expect_failure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-01 09:24:57 +08:00
test_must_fail git merge -s subtree E^0 &&
test_path_is_missing .git/MERGE_HEAD
t6044: new merge testcases for when index doesn't match HEAD With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10 14:13:37 +08:00
'
test_done
Reference in New Issue Copy Permalink