Elijah Newren <newren@xxxxxxxxx> writes: > Really? Wow. I never had any clue that this was possible and never > ran across it. Is it documented anywhere? Probably a test script for "read-tree -m" has a fairly detailed and comprehensive table of possible scenarios. Multiple stage #1 entries were introduced to primarily support the protection against "criss-cross merge" that confuses the history and it is used by the resolve backend, IIRC. The implementation of octopus we have does not actually use multiple stage #3 entries but just does many two-parent merges in sequence. It started its life as a POC & stop-gap implementation while waiting for the "real thing" that merges with multiple stage #3 entries, but it turned out to be good enough for a relatively rare (and now discouraged mostly due to bisection efficiency reasons) style of merge and left in that shape until now.
