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.
