merge: fix numerus bugs around "trivial merge" area
authorJunio C Hamano <gitster@pobox.com>
Sat, 23 Aug 2008 19:56:57 +0000 (12:56 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sun, 24 Aug 2008 01:17:22 +0000 (18:17 -0700)
commit446247db78a733f44d2470afb1f1983d28058159
treec86cccdb597c9c7569f432d1e4cd1da7e492d7a3
parent913e0e99b6a6e63af6a062622a1f94bd78fd8052
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>
builtin-merge.c
t/t3030-merge-recursive.sh
t/t7600-merge.sh
t/t7605-merge-resolve.sh