Re: Collaborative conflict resolution feature request

From: Philip Oakley <philipoakley@iee.email>
Date: Jun 15, 2020, 19:37 UTC
Message-ID: <8b0e65ec-02c1-a1c7-b363-e81f37f3fe7e@iee.email>
In-Reply-To: <xmqq1rmgxo67.fsf@gitster.c.googlers.com>

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

Show 7 quoted lines

> Philip Oakley <philipoakley@iee.email> writes:
>
>> 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.

Show 5 quoted lines

>
> 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).