Re: Collaborative conflict resolution feature request

[Sergey Organov <sorganov@gmail.com>]

"Curtin, Eric" <Eric.Curtin@dell.com> 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.