(Obsolete) Better modelling of conflicts

[ilyagr]

Update 2: Pretty much everything I wrote here is obsolete. I may or may not replace this with a new discussion at some point.

Update: The recursive idea was already discussed in #5. The other idea here is quite simple: "let's keep track of deletions and which removes correspond to each add". See the next comment.

I think that jj's understanding of complicated conflicts as a set of "adds" and "removes", while excellent, could be better. I'm not sure if this is worth spending much time on, since complicated conflicts are rare, but I wanted to write it down while I remember it.

I think there should always be N adds and N-1 removes for every conflict. This preserves the correspondence of which two adds correspond to every remove (since the adds usually come from revisions and a remove is usually obtained from a common ancestor of two revisions). Currently, if we have 5 adds and 2 removes, the correspondence is lost and we don't know which 2 conflicts each remove works as a base for.

Another piece of information that's lost but useful for resolving conflicts are common ancestors of bases. Update: On second thought, I'm not sure just how useful tracking this would be.

I think the following would be better:

• For N > 1, an n-sided conflict consists of N sides and 1 base. Each side is either a reference to a file in a tree that is not a conflict (as an "add" is now) or a "Deletion" marker if the corresponding file was deleted on that side.
• The base is required to be an N-1-sided conflict. Its sides correspond to what we currently call "removes".
• The i-th side of the base is conceptually (and, for normal merges, literally) the common ancestor of two sides (the ith and the i+1st, to be specific) of the parent conflict.
• A 1-sided conflict consists of 1 side and no base.

This has all the information to resolve the conflict with repeated 3-way merges.

It might be also interesting to check how pijul does this before implementing it.

[ilyagr]

On second thought, this is still missing something. I keep going back and forth between the idea above and the idea of having N-1 bases, each of which can be a file, a deletion, or a conflict. Having the base be a conflict is tempting for the recursion, but might not be extremely helpful.

What I certainly believe, and what this idea started with, is that each "remove" should correspond to exactly two "add"s and deletions should be tracked explicitly.

[martinvonz]

We talked about this on Discord yesterday. For reference, there's some earlier discussion in #5.