Re: Collaborative conflict resolution feature request

From: Curtin, Eric <eric.curtin@dell.com>
Date: Jun 18, 2020, 08:53 UTC
Message-ID: <BY5PR19MB3400CD5482C8837E41DFEAF2909B0@BY5PR19MB3400.namprd19.prod.outlook.com>
In-Reply-To: <CANgJU+WfW4mKotMwFS+2Kaq1pDysgJutJ2NhUvyvGgowk8JXsg@mail.gmail.com>

Show 6 quoted lines

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

I understand what you guys are saying, I agree merge early, merge often does work best and it's what I've most often used. Our branching strategy is split by subsystem (and sometimes specific features). So contributors are not merging to the same long-term branches. So merge early, merge often, doesn't help with conflicts.

Why? We don't have so much automated tests, etc. And that's not an easy problem to solve although we are trying to improve in this area. For us to make worthwhile tests, we would have to emulate a lot of hardware from external vendors. Out test hardware is often shared among many. So branching ensures that if we hit problems, it most likely came from within our group, in the area of the code we are most knowledgeable about.

And when your branching strategy is like this, it ends up being the branch managers merging and having to fix conflicts, not the individual contributors. In our git repo you will see broken commits with these delimiters in (<<<< ==== >>>>) in order to "fake" this kind of collaborative conflict resolution feature as described in the initial email.

Regards,

Eric Curtin

Software Engineer Ovens Campus, Cork, Ireland

Dell EMC