Re: Collaborative conflict resolution feature request

From: Philip Oakley <philipoakley@iee.email>
Date: Jun 13, 2020, 13:14 UTC
Message-ID: <432b9e0b-eedf-6d39-ebc0-0416f8574afc@iee.email>
In-Reply-To: <BY5PR19MB3400AE170C9F5FF501D27B18909E0@BY5PR19MB3400.namprd19.prod.outlook.com>

On 13/06/2020 13:38, Curtin, Eric wrote:

> Both great ideas! And have the same theory right? Merge until you come across the first conflicting commit in a branch to make the conflicts smaller right?

I've also responded to the issue on GitHub:

"Do you have an implicit XY-problem where your processes are reinforcing historical bad habits "we merge branches that have been forked for months"? It sounds like the process is saying "We enjoy technical debt" (of delaying the merge until it's really bad...).

Maybe have a parallel 'merge' branch that is used (say weekly) to do trial merges and will essentially record the conflict resolutions while they are fresh in folks memories. That branch is distinct from, either of the two main branches, but will act as a filter and a hand rail to highlight future difficulties."

Implicit in Git is the use of small patches, easy branching and frequent merges, available to the individual coder. Most older "change control systems" focus on *stopping* change. Git promotes change, because reproduction & testing is cheap (almost zero). Git provides *authentication* of code versions. The changes in the underlying materials (from hardware to software), i.e. to bits and bytes, ripped up the old rule book.

Also look at 'rerere'.

Show 41 quoted lines

>
> Thanks so much for your help! Any alternative ideas? I'm definitely going to try both techniques, although imerge seems like an automation of the first idea.
>
> Anybody ever think of rewriting the imerge tool in C or whatever to get in merged into mainline git? Potentially I could do it as part of my masters thesis if Michael H and the git open source community agreed?
>
> Regards,
>
> Eric Curtin
>
> Software Engineer
> Ovens Campus,
> Cork,
> Ireland
>
> Dell EMC
>
> From: Christian Couder <christian.couder@gmail.com>
> Sent: Saturday 13 June 2020 13:08
> To: Curtin, Eric <Eric.Curtin@dell.com>
> Cc: git@vger.kernel.org <git@vger.kernel.org>; Geary, Niall <Niall.Geary@dell.com>; rowlands, scott <Scott.Rowlands@dell.com>; Michael Haggerty <mhagger@alum.mit.edu>
> Subject: Re: Collaborative conflict resolution feature request 
>  
>
> [EXTERNAL EMAIL] 
>
> Hi,
>
> On Fri, Jun 12, 2020 at 4:11 PM Curtin, Eric <Eric.Curtin@dell.com> wrote:
>
>> Is there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?
> You might want to take a look at Michael Haggerty's 'git imerge':
>
> https://github.com/mhagger/git-imerge
>
>> I also opened this as an issue in github as I feel it could be solved by either tool potentiall:
>>
>> https://github.com/isaacs/github/issues/1816
> I also made the same suggestion on the issue.
>
> Best,
> Christian.