Replies: 2 comments
-
On second thought, this is still missing something. I keep going back and forth between the idea above and the idea of having 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. |
Beta Was this translation helpful? Give feedback.
-
We talked about this on Discord yesterday. For reference, there's some earlier discussion in #5. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
i
-th side of the base is conceptually (and, for normal merges, literally) the common ancestor of two sides (thei
th and thei+1
st, to be specific) of the parent conflict.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.
Beta Was this translation helpful? Give feedback.
All reactions