Re: Collaborative conflict resolution feature request
- From
Chris Torek <chris.torek@gmail.com>
- Date
- Jun 16, 2020, 15:56 UTC
- Message-ID
- <CAPx1Gvf5R6b1NoUWHkaqLMaj6dr51hERVvuVe1X9k3NEafnBhg@mail.gmail.com>
- In-Reply-To
- <CAPx1GvdT6sZRtu8q1R9=fA-mE9pi1Ag-gKEzQfwbGap+KqSoSg@mail.gmail.com>
On Mon, Jun 15, 2020 at 10:32 AM Chris Torek <chris.torek@gmail.com> 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