Re: Collaborative conflict resolution feature request

["Curtin, Eric" <Eric.Curtin@dell.com>]

> 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