summaryrefslogtreecommitdiff
path: root/t/t7605-merge-resolve.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-04-12builtin/merge.c: fix a bug with trivial mergesLibravatar Elijah Newren1-1/+1
If read_tree_trivial() succeeds and produces a tree that is already in the object store, then the index is not written to disk, leaving it out-of-sync with both HEAD and the working tree. In order to write the index back out to disk after a merge, write_index_locked() needs to be called. For most merge strategies, this is done from try_merge_strategy(). For fast forward updates, this is done from checkout_fast_forward(). When trivial merges work, the call to write_index_locked() is buried a little deeper: merge_trivial() -> write_tree_trivial() -> write_cache_as_tree() -> write_index_as_tree() -> write_locked_index() However, it is only called when !cache_tree_fully_valid(), which is how this bug is triggered. But that also shows why this bug doesn't affect any other merge strategies or cases. Add a direct call to write_index_locked() from merge_trivial() to fix this issue. Since the indirect call to write_locked_index() was conditional on cache_tree_fully_valid(), it won't be written twice. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12t7605: add a testcase demonstrating a bug with trivial mergesLibravatar Elijah Newren1-1/+5
Repeating a trivial merge more than once will leave the index out of sync, despite being clean before the merge and operating on the exact same heads as the first run. The recorded merge has the correct tree and the working tree is brought up to date, it is just the index that is left as it was before the merge. Every attempt to repeat the merge beyond the first will leave the index in the same weird out-of-sync state. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t7200 - t9001)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t7201-t9001. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-23merge: fix numerus bugs around "trivial merge" areaLibravatar Junio C Hamano1-1/+3
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-07-13Add a new test for git-merge-resolveLibravatar Miklos Vajna1-0/+46
Actually this is a simple test, just to ensure merge-resolve properly calls read-tree. read-tree itself already has more complex tests. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>