Re: Collaborative conflict resolution feature request

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

Hi Guys,

Yes I think you all understand the conundrum well. Conflict resolution
by definition is a collaborative effort, but git doesn't support it as a,
collaborative effort, only one user can resolve it in git. It will be hard to
change my whole orgs thinking around avoiding conflicts or making
them easier conflicts to solve. There will always be some conflicts.

>  * developers do test merges on temporary branches between their
>    feature branch and the main development – or other feature
>    branches if necessary (maybe create test merges on a regular
>    basis to minimize the new conflicts)
>  * these temporary branches get pushed, but not merged to other
>    branches
>  * the branch manager fetches these branches and uses
>    `rerere-train.sh` to fill the local rerere database with
>    conflict resolutions from the test merges
>  * the temporary branches get deleted
>  * the recorded resolutions get reused when needed (keep in mind
>    rerere's gc config, see gc.rerereResolved and gc.rerereUnresolved)

I certainly want to play around with rere and see if it helps things. I
suspect if I shared a technique like this with the 100 or so developers
on the project this will be deemed too complex though.

A per file solution isn't great either as some files can be large.
Per-conflict (between <<<< >>>> in a plain old text editor) is
reasonable.

What would be most ideal is a:

git merge
fix some conflicts, not others
git push

so someone else can work on it kind of solution....

We don't do plaintext email patches, we do typically merge
things via git cli/protocol or via GitHub Pull Request.

Regards,

Eric Curtin

Software Engineer
Ovens Campus,
Cork,
Ireland

Dell EMC