Re: Collaborative conflict resolution feature request

From: Curtin, Eric <eric.curtin@dell.com>
Date: Jun 18, 2020, 09:28 UTC
Message-ID: <BY5PR19MB34004D9F72F6B66376F8E986909B0@BY5PR19MB3400.namprd19.prod.outlook.com>
In-Reply-To: <BY5PR19MB3400CD5482C8837E41DFEAF2909B0@BY5PR19MB3400.namprd19.prod.outlook.com>

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

Show 6 quoted lines

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

Regards,

Eric Curtin

Software Engineer Ovens Campus, Cork, Ireland

Dell EMC