Re: Collaborative conflict resolution feature request

Philip Oakley [off-list ref] writes:

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

quoted

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?

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.