Re: Collaborative conflict resolution feature request

From: Curtin, Eric <eric.curtin@dell.com>
Date: Jun 17, 2020, 18:32 UTC
Message-ID: <BY5PR19MB34004535CCF180CE5C63B731909A0@BY5PR19MB3400.namprd19.prod.outlook.com>
In-Reply-To: <fe2cd745-29a7-3341-d321-4199b184bc96@mail.de>

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.

Show 12 quoted lines

>  * 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