Re: Collaborative conflict resolution feature request

[demerphq <demerphq@gmail.com>]

On Thu, 18 Jun 2020 at 11:28, Curtin, Eric <Eric.Curtin@dell.com> wrote:
>
> > 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.
>
> I think concurrent doesn't make sense, only sequential.
>
> > I find that the solution in these cases is to first use interactive
> > rebase to squash and reorganize the commits in the branches so you
> > have a nice clean patch sequence. Once you have the branches cleaned
> > up and squashed into a sequence of reasonable topic based chunks you
> > then merge, sometimes it even means you dont get conflicts at all, git
> > merge is pretty smart.
>
> Again, as said in the initial email, anything that rewrites history,
> recreates SHA's (such as rebase, squash, etc.) on a remote
> branch is not allowed in our repo. Of course with unpushed
> commits you can do some of these things as the remote end
> knows no different.

Ah I see, I missed that detail. We have a similar rule at work but
only for the "trunk" branch (what most people call "master"), topic
branches are allowed to change before the merge to trunk.

I guess there is no way to convince your policy makers that if commit
A and B are different but have the same tree hash they refer to the
same state on the disk? I have had audit conversations like that.

Anyway, sorry my reply wasn't helpful. Good luck.

cheers,
Yves