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@xxxxxxxxx> --- t/t6044-merge-unrelated-index-changes.sh | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/t/t6044-merge-unrelated-index-changes.sh b/t/t6044-merge-unrelated-index-changes.sh index f9c2f8179..92ec55255 100755 --- a/t/t6044-merge-unrelated-index-changes.sh +++ b/t/t6044-merge-unrelated-index-changes.sh @@ -126,6 +126,17 @@ test_expect_failure 'recursive, when merge branch matches merge base' ' test_path_is_missing .git/MERGE_HEAD ' +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 +' + test_expect_success 'octopus, unrelated file touched' ' git reset --hard && git checkout B^0 && -- 2.18.0.137.g2a11d05a6.dirty
