Thread (4 messages) 4 messages, 3 authors, 2020-06-16

Re: Collaborative conflict resolution feature request

flat view

From: Chris Torek <hidden>
Date: 2020-06-16 15:56:46

On Mon, Jun 15, 2020 at 10:32 AM Chris Torek [off-list ref] wrote:
I've thought about this (some) myself in the past.  It seems to me that what
is needed is the ability to pass the complete unmerged state on.
A few further thoughts:

 * Given one or more saved merges and either a clean state or an
   ongoing merge, we need a tool to combine these.  There are a lot of
   corner cases here but in general, if merge X has file F in conflict and
   merge Y has file F resolved, we can take the resolution from Y.

 * Partial merges (in the work-tree copy of a file) that are not yet added
   may be the trickiest.  A simple heuristic would be to look for the
   conflict markers and see if one work-tree copy has a resolution
   where another work-tree copy has a conflict.  Or, though this is
   harder, use the ours/theirs copies in the saved index trees to find
   actual conflicted regions and compare this to the work-tree copy
   to find resolved regions.

 * There is also an obvious question about what to do when combining
   two different proposed resolutions where the stage-zero and/or
   work-tree copies of the files don't match.

None of these preclude the basic ability to save and restore—and of
course transport, through fetch/push—the unmerged state, which I think
is the required enabling technology.  The ideas above are more for
combining parallel merge efforts.  If it's acceptable for dev A to merge
his/her part and pass the result to dev B, who merges theirs, and so
on, the above is not required.

Chris
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help