[PATCH 0/3] Handling merge conflicts a bit more gracefully
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:59
This series consists of three patches.
[PATCH 1/3] read-tree.c: rename local variables used in 3-way merge code.
[PATCH 2/3] read-tree -m 3-way: loosen index requirements that is too strict.
[PATCH 3/3] read-tree -m 3-way: handle more trivial merges internally
You may have noticed that I already described some "alternative
semantics" in the 3-way merge test script t1000. This set of
patches implements some of them, namely the following 5 cases:
O A B result index requirements
-------------------------------------------------------------------
5 missing exists A==B take A must match A, if exists.
------------------------------------------------------------------
6 exists missing missing remove must not exist.
------------------------------------------------------------------
8 exists missing O==B remove must not exist.
------------------------------------------------------------------
10 exists O==A missing remove must match A and be
up-to-date, if exists.
------------------------------------------------------------------
14 exists O==A O!=B take B if exists, must either (1)
match A and be up-to-date,
or (2) match B.
-------------------------------------------------------------------
The first patch is to match the local variable names used in the
functions involved to the names used in the case matrix.
Case #14 is resolved identically as the old code does, but the
index requirement old code placed on this case was stricter than
necessary. In this case, satisfying the usual rule of "match A
and be up-to-date if exists" is certainly OK, but additionally,
if the original index matches the tree being merged (without
even being up-to-date) is also permissible, because there would
be no information loss or work-tree clobbering if we allowed it.
The second patch in the series corrects this.
Case #5, #6, #8, and #10 were traditionally kept unmerged in the
index file when read-tree is done, and resolving them was left
to the script. By resolving these internally, we can loosen the
index requirements without compromising correctness for case #5.
Other three cases could still be left for the "script policy"
because this change does not affect the index requirements for
these cases, but it was simple enough to implement them and this
would not be too controversial a change. The third patch in the
series implements these changes.