merge-recursive: increase marker length with depth of recursion
authorElijah Newren <newren@gmail.com>
Thu, 8 Nov 2018 04:40:24 +0000 (20:40 -0800)
committerJunio C Hamano <gitster@pobox.com>
Thu, 8 Nov 2018 05:23:53 +0000 (14:23 +0900)
commitb2a7942b8bcf397d9a5d3bb6671853755e14de60
treebc05eff4994913792f1abcd745451e9e1f315ec5
parentb28eeb3092fd12e24485fbadebfa57df457dd09a
merge-recursive: increase marker length with depth of recursion

Later patches in this series will modify file collision conflict
handling (e.g. from rename/add and rename/rename(2to1) conflicts) so
that multiply nested conflict markers can arise even before considering
conflicts in the virtual merge base.  Including the virtual merge base
will provide a way to get triply (or higher) nested conflict markers.
This new way to get nested conflict markers will force the need for a
more general mechanism to extend the length of conflict markers in order
to differentiate between different nestings.

Along with this change to conflict marker length handling, we want to
make sure that we don't regress handling for other types of conflicts
with nested conflict markers.  Add a more involved testcase using
merge.conflictstyle=diff3, where not only does the virtual merge base
contain conflicts, but its virtual merge base does as well (i.e. a case
with triply nested conflict markers).  While there are multiple
reasonable ways to handle nested conflict markers in the virtual merge
base for this type of situation, the easiest approach that dovetails
well with the new needs for the file collision conflict handling is to
require that the length of the conflict markers increase with each
subsequent nesting.

Subsequent patches which change the rename/add and rename/rename(2to1)
conflict handling will modify the extra_marker_size flag appropriately
for their new needs.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ll-merge.c
ll-merge.h
merge-recursive.c
t/t6036-recursive-corner-cases.sh