merge: do not exit restore_state() prematurely
Previously, if the user:
* Had no local changes before starting the merge
* A merge strategy makes changes to the working tree/index but returns
with exit status 2
Then we'd call restore_state() to clean up the changes and either let
the next merge strategy run (if there is one), or exit telling the user
that no merge strategy could handle the merge. Unfortunately,
restore_state() did not clean up the changes as expected; that function
was a no-op if the stash was a null, and the stash would be null if
there were no local changes before starting the merge. So, instead of
"Rewinding the tree to pristine..." as the code claimed, restore_state()
would leave garbage around in the index and working tree (possibly
including conflicts) for either the next merge strategy or for the user
after aborting the merge. And in the case of aborting the merge, the
user would be unable to run "git merge --abort" to get rid of the
unintended leftover conflicts, because the merge control files were not
written as it was presumed that we had restored to a clean state
already.
Fix the main problem by making sure that restore_state() only skips the
stash application if the stash is null rather than skipping the whole
function.
However, there is a secondary problem -- since merge.c forks
subprocesses to do the cleanup, the in-memory index is left out-of-sync.
While there was a refresh_cache(REFRESH_QUIET) call that attempted to
correct that, that function would not handle cases where the previous
merge strategy added conflicted entries. We need to drop the index and
re-read it to handle such cases.
(Alternatively, we could stop forking subprocesses and instead call some
appropriate function to do the work which would update the in-memory
index automatically. For now, just do the simple fix.)
Also, add a testcase checking this, one for which the octopus strategy
fails on the first commit it attempts to merge, and thus which it
cannot handle at all and must completely bail on (as per the "exit 2"
code path of commit 98efc8f3d8 ("octopus: allow manual resolve on the
last round.", 2006-01-13)).
Reported-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-23 01:53:18 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description="Test that merge state is as expected after failed merge"
|
|
|
|
|
|
|
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
|
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
2023-10-03 20:27:24 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
merge: do not exit restore_state() prematurely
Previously, if the user:
* Had no local changes before starting the merge
* A merge strategy makes changes to the working tree/index but returns
with exit status 2
Then we'd call restore_state() to clean up the changes and either let
the next merge strategy run (if there is one), or exit telling the user
that no merge strategy could handle the merge. Unfortunately,
restore_state() did not clean up the changes as expected; that function
was a no-op if the stash was a null, and the stash would be null if
there were no local changes before starting the merge. So, instead of
"Rewinding the tree to pristine..." as the code claimed, restore_state()
would leave garbage around in the index and working tree (possibly
including conflicts) for either the next merge strategy or for the user
after aborting the merge. And in the case of aborting the merge, the
user would be unable to run "git merge --abort" to get rid of the
unintended leftover conflicts, because the merge control files were not
written as it was presumed that we had restored to a clean state
already.
Fix the main problem by making sure that restore_state() only skips the
stash application if the stash is null rather than skipping the whole
function.
However, there is a secondary problem -- since merge.c forks
subprocesses to do the cleanup, the in-memory index is left out-of-sync.
While there was a refresh_cache(REFRESH_QUIET) call that attempted to
correct that, that function would not handle cases where the previous
merge strategy added conflicted entries. We need to drop the index and
re-read it to handle such cases.
(Alternatively, we could stop forking subprocesses and instead call some
appropriate function to do the work which would update the in-memory
index automatically. For now, just do the simple fix.)
Also, add a testcase checking this, one for which the octopus strategy
fails on the first commit it attempts to merge, and thus which it
cannot handle at all and must completely bail on (as per the "exit 2"
code path of commit 98efc8f3d8 ("octopus: allow manual resolve on the
last round.", 2006-01-13)).
Reported-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-23 01:53:18 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'Ensure we restore original state if no merge strategy handles it' '
|
|
|
|
|
test_commit --no-tag "Initial" base base &&
|
|
|
|
|
|
|
|
|
|
for b in branch1 branch2 branch3
|
|
|
|
|
do
|
|
|
|
|
git checkout -b $b main &&
|
|
|
|
|
test_commit --no-tag "Change on $b" base $b || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
|
|
|
|
git checkout branch1 &&
|
|
|
|
|
# This is a merge that octopus cannot handle. Note, that it does not
|
|
|
|
|
# just hit conflicts, it completely fails and says that it cannot
|
|
|
|
|
# handle this type of merge.
|
|
|
|
|
test_expect_code 2 git merge branch2 branch3 >output 2>&1 &&
|
|
|
|
|
grep "fatal: merge program failed" output &&
|
|
|
|
|
grep "Should not be doing an octopus" output &&
|
|
|
|
|
|
|
|
|
|
# Make sure we did not leave stray changes around when no appropriate
|
|
|
|
|
# merge strategy was found
|
|
|
|
|
git diff --exit-code --name-status &&
|
|
|
|
|
test_path_is_missing .git/MERGE_HEAD
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_done
|