Re: Collaborative conflict resolution feature request

>
> > 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.