merge: fix numerus bugs around "trivial merge" area

The "trivial merge" codepath wants to optimize itself by making an
internal call to the read-tree machinery, but it does not read the index
before doing so, and the codepath is never exercised.  Incidentally, this
failure to read the index upfront means that the safety to refuse doing
anything when the index is unmerged does not kick in, either.

These two problem are fixed by using read_cache_unmerged() that does read
the index before checking if it is unmerged at the beginning of
cmd_merge().

The primary logic of the merge, however, assumes that the process never
reads the index in-core, and the call to write_cache_as_tree() it makes
from write_tree_trivial() will always read from the on-disk index that is
prepared the strategy back-ends.  This assumption is now broken by the
above fix.  To fix this issue, we now call discard_cache() before calling
write_tree_trivial() when it wants to write the on-disk index as a tree.

When multiple strategies are tried, their results are evaluated by reading
the resulting index and inspecting it.  The codepath needs to make a call
to read_cache() for each successful strategy, and for that to work, they
need to discard_cache() the one read by the previous round.

Also the "trivial merge" forgot that the current commit is one of the
parents of the resulting commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 9 insertions, 0 deletions

diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index fee8fb77d4..dbc90bc416 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -498,4 +498,13 @@ test_expect_success 'merge fast-forward in a dirty tree' '
 
 test_debug 'gitk --all'
 
+test_expect_success 'in-index merge' '
+	git reset --hard c0 &&
+	git merge --no-ff -s resolve c1 > out &&
+	grep "Wonderful." out &&
+	verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
 test_done