Re: Collaborative conflict resolution feature request

[Junio C Hamano <gitster@pobox.com>]

Philip Oakley <philipoakley@iee.email> writes:

> Hi Junio,
> On 15/06/2020 17:57, Junio C Hamano wrote:
>> 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?

No.

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

Yes.  The question is, that division of labor is agreed between
humans dev.a and dev.b, but somehow need to be encoded in the data
passed from dev.a to dev.b that says "I've done with As and am
comfortable with the result; I didn't even look at Bs, but it's your
turn to deal with them".

After seeing "git pull" leave conflicts, "git checkout HEAD -- Bs"
(or checkout may be done out of MERGE_HEAD?  I dunno) would be a way
to get dev.a concentrate on As only, but the result cannot be tested
sensibly anyway, and it cannot be committed as the result as taking
"ours" or "theirs" for Bs was not dev.a's intention.  How to express
that "I didn't do anything to Bs" in such a way that can be
distinguished from "I did look at Bs, and I believe taking all from
my HEAD is the right resolution" was what I asked.