Re: Collaborative conflict resolution feature request

Hi Junio,
On 15/06/2020 17:57, Junio C Hamano wrote:

Philip Oakley [off-list ref] writes:

quoted

It could be effectively a special strategy. IIUC the '--' separator is
already supported by the underlying parser code, so may not be that
hard? (perhaps a local contribution to the codebase;-). Just a thought.

Assuming that there are paths A and B that would leave conflict in
an attempted merge between commits X and Y,

Are we confusing the file merge X.A and Y.A with X.B and Y.B?

The scenario envisaged is that dev.a has responsibility over the .A file
merge, while dev.b will handle the merge for .B merge (e.g. different
parts of the driver code).

 you somehow resolve the
conflict in A and leave B unresolved,

So dev.a has resolved the .A conflicts, and the .B file(s) is still in
the .ours state - no conflict (i.e. we have an 'ours' strategy for all
files not in the A path(s)).

 what would you pass to the
other person and ask to resolve the conflicts in B?

Yes the merge that dev.a has performed is passed onto dev.b to complete
a second merge, apparently of the same commit, which is essentially
similar to cherry picking the .B files from the .theirs commit [1].

  It cannot be a
merge commit that records X and Y as its parents and a single tree
object as the result, because the whole point of this is that you do
not even know what to record for B.

if no merge is attempted for paths not in the A set then the other B set
are never 'in conflict'. As I understand Eric's conundrum, it's that a
plain merge throws too many conflicts at the one developer. This
suggestion would be the way to reduce the number of conflicts just to
the paths the one dev can handle. A lot will depend on how Eric's
problem is partitioned and the depth of the overlaps.

I think the most important and useful part of this is to design the
data format used for that task of passing from you to the other
person.  The way to specify which paths are yours etc. are much less
interesting and trivial part of the story, I would think.

A list of un-merged paths (i.e. not attempted) is one such format, surely?

Philip

[1] actually, it's more like a soft checkout or restore of those files
from the merging branch. (exchange format becomes list of merged
paths...).  Which  then leads easily to the available `git checkout`
options (assuming the approach has validity for Eric's scenario).