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
cf69f2af08
git/t/t6044-merge-unrelated-index-changes.sh

191 lines
3.8 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
'
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_expect_failure '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
'
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
test_expect_failure 'merge-recursive, when index==head but head!=HEAD' '
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-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