"Curtin, Eric" <Eric.Curtin@xxxxxxxx> writes: > Hi Guys, > > Yes I think you all understand the conundrum well. Conflict resolution > by definition is a collaborative effort, but git doesn't support it as a, > collaborative effort, only one user can resolve it in git. [As a side-note, I don't agree with "by definition" part of the statement, nor with "only one user" part, so what is left?] What I'd like to stress though is that there is a pitfall here: is it feasible to try to support concurrent conflict resolution, or is it to be sequential (even if in multiple turns)? I incline to the latter. Concurrent conflict resolution would lead to conflicts in conflict resolutions, that already sounds too complex to be useful for my taste, and we already are in recursion that must be stopped somewhere, so it's tempting to stop it one level up. Admittedly, one can try to avoid conflicts in resolutions by splitting content to independent parts (where Git is not easily applicable by design, being the tool that manages entire content), but such a split doesn't sound realistic, as if it were possible, it'd be easier to apply it to avoid original conflicts in the first place. Then, a non-trivial conflict resolution often needs changes elsewhere anyway, making strict content split again problematic. OTOH, anything sequential is intrinsically difficult for a distributed system like Git, so it probably should better be implemented elsewhere. This approach is simplified by the fact that fortunately Git doesn't care how exactly you come-up with the resulting merge commit[*], so one is free to use whatever external tool to achieve his goals. -- Sergey [*] Well, it actually does care in some corner cases, e.g., when it drops or tries to re-create merges on rebase, and that will only be eliminated once "evil merge" concept is finally buried, for better.
