On Mon, Jun 15, 2020 at 10:32 AM Chris Torek <chris.torek@xxxxxxxxx> 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
