2008-07-12 22:33:35 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
2008-09-03 08:59:33 +00:00
|
|
|
test_description='git merge
|
2008-07-12 22:33:35 +00:00
|
|
|
|
|
|
|
Testing the resolve strategy.'
|
|
|
|
|
2022-11-08 18:17:43 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2008-07-12 22:33:35 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
echo c0 > c0.c &&
|
|
|
|
git add c0.c &&
|
|
|
|
git commit -m c0 &&
|
|
|
|
git tag c0 &&
|
|
|
|
echo c1 > c1.c &&
|
|
|
|
git add c1.c &&
|
|
|
|
git commit -m c1 &&
|
|
|
|
git tag c1 &&
|
|
|
|
git reset --hard c0 &&
|
|
|
|
echo c2 > c2.c &&
|
|
|
|
git add c2.c &&
|
|
|
|
git commit -m c2 &&
|
|
|
|
git tag c2 &&
|
|
|
|
git reset --hard c0 &&
|
|
|
|
echo c3 > c2.c &&
|
|
|
|
git add c2.c &&
|
|
|
|
git commit -m c3 &&
|
|
|
|
git tag c3
|
|
|
|
'
|
|
|
|
|
2016-04-10 06:13:39 +00:00
|
|
|
merge_c1_to_c2_cmds='
|
2008-07-12 22:33:35 +00:00
|
|
|
git reset --hard c1 &&
|
|
|
|
git merge -s resolve c2 &&
|
|
|
|
test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
|
|
|
|
test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
|
|
|
|
test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
|
|
|
|
git diff --exit-code &&
|
|
|
|
test -f c0.c &&
|
|
|
|
test -f c1.c &&
|
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>
2008-08-23 19:56:57 +00:00
|
|
|
test -f c2.c &&
|
|
|
|
test 3 = $(git ls-tree -r HEAD | wc -l) &&
|
|
|
|
test 3 = $(git ls-files | wc -l)
|
2008-07-12 22:33:35 +00:00
|
|
|
'
|
|
|
|
|
2016-04-10 06:13:39 +00:00
|
|
|
test_expect_success 'merge c1 to c2' "$merge_c1_to_c2_cmds"
|
|
|
|
|
2016-04-10 06:13:40 +00:00
|
|
|
test_expect_success 'merge c1 to c2, again' "$merge_c1_to_c2_cmds"
|
2016-04-10 06:13:39 +00:00
|
|
|
|
2008-07-12 22:33:35 +00:00
|
|
|
test_expect_success 'merge c2 to c3 (fails)' '
|
|
|
|
git reset --hard c2 &&
|
|
|
|
test_must_fail git merge -s resolve c3
|
|
|
|
'
|
|
|
|
test_done
|