Re: Collaborative conflict resolution feature request

From: demerphq <demerphq@gmail.com>
Date: Jun 18, 2020, 08:11 UTC
Message-ID: <CANgJU+WfW4mKotMwFS+2Kaq1pDysgJutJ2NhUvyvGgowk8JXsg@mail.gmail.com>
In-Reply-To: <BY5PR19MB34007DEED68D13003C614F5F909C0@BY5PR19MB3400.namprd19.prod.outlook.com>

On Mon, 15 Jun 2020 at 11:30, Curtin, Eric <Eric.Curtin@dell.com> wrote:

Show 14 quoted lines

>
> > An aside that probably would not directly help Eric, but I know the
> > above workflow helps reasonably well.  The 'pu' branch is rebuilt
> > not on top of 'next', but is rebuilt with all topics (including
> > those already in 'next') in flight directly on top of 'master',
> > which serves as a way to anticipate conflicts that will require
> > resolution in the future before the topics can enter 'next' branch.
>
> Out of all the currently available options this solution helps. Thanks
> Junio! I played with incremental merge techniques this weekend.
> One problem with incrementally merging is that you start fixing
> conflicts that are later invalidated by subsequent commits. So it
> seems you end up doing more conflict resolution than necessary.
> Unless I'm misusing the technique.

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.

And after that you change your workflows so the rule is that whomever pushes first to the "trunk branch" wins, and the other guy has to do the conflict resolution. People will start merging earlier and more often so they can keep the conflicts to a minimum. :-) In other words I second what Philip Oakley said about bad workflows. Merge early, merge often, rollout early, rollout often, vote early, vote often. :-)

cheers, Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"