Re: Collaborative conflict resolution feature request

From: Sergey Organov <sorganov@gmail.com>
Date: Jun 15, 2020, 12:55 UTC
Message-ID: <874krczdx9.fsf@osv.gnss.ru>
In-Reply-To: <BY5PR19MB3400EB9AD87DFE612AFD5CC390810@BY5PR19MB3400.namprd19.prod.outlook.com>

"Curtin, Eric" <Eric.Curtin@dell.com> writes:

Show 22 quoted lines

> Hi Guys,
>
> Sometimes in our private git instance in the company I work for we
> merge branches that have been forked for months and there can be
> several or more people involved in the conflict resolution.
>
> At the moment we have two options:
>
> - One person, a branch manager, solves them by ringing people, holding
> meetings, using best judgement, etc.
> - Somebody solves the conflicts they are involved with, marks
> everything as resolved and pushes (leaving <<< ==== >>>> delimiters in
> for unsolved conflicts) for the next person to continue. This sort of
> works although you falsely mark everything as resolved, leaving merge
> tools useless and many broken, unbuildable commits around in the
> branch.
>
> Note: rebase and squashing commits is banned in our org, basically
> anything that would rewrite history on a remote branch.
>
> Is there any existing or upcoming feature in git that could help make
> conflict resolution a more distributed, collaborative kind of task?

That'd be great.

What we sometimes do when such a case appears (rather rarely due to frequent merges, I admit) is to copy /entire/ git directory holding the merge in progress to the next person in charge. This is the only way that I'm aware of that keeps ability to do things like:

  $ f=foo.cc; git diff :1:./$f  :3:./$f

and

  $ f=foo.cc; git diff :1:./$f  :2:./$f

that helps a lot with complicated conflicts.

So, if such a solution ever appears, it'd apparently need a method of sharing or re-creating (parts of) the index? Doesn't sound as an easy problem.

-- Sergey