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>
