Re: Collaborative conflict resolution feature request

From: Curtin, Eric <eric.curtin@dell.com>
Date: Jun 21, 2020, 00:20 UTC
Message-ID: <BY5PR19MB3400DC6B6065C1FFF2ED289890990@BY5PR19MB3400.namprd19.prod.outlook.com>
In-Reply-To: <CAP8UFD2t6OVFWjm76oy=+Fgo1UUepwHTpOWM8vmCYzs9hSy_ug@mail.gmail.com>

Show 8 quoted lines

> I think it could be an interesting feature to add to Git, as I agree
> that some people often have this kind of issues with conflicts.
>
> What could perhaps work is to develop a new command, maybe called `git
> conflict` with subcommands for example to load, save and maybe push,
> fetch and resolve partial resolutions of conflicts. The conflicts
> could perhaps be stored as commits in the "refs/conflicts/" ref
> namespace.

Yes and actually the more I read about things like `git rerere`, most of the components are already there in git. What this concept kind of is, is a pushable git rerere cache. A workflow could be something like:

git merge/rebase # fails with conflicts, maybe a prompt that to tell the user that some conflict resolutions have already been pushed git rerere pop/apply # apply the already pushed conflicts # fix your conflict with whatever technique or tool you prefer git rerere create # commit your rerere (stash uses the term create) writing a message explaining why you resolved this conflict in a certain way git push # or maybe `git rerere push` so the next user can "git fetch/git merge/etc." and work on the conflict resolution

And maybe add some other git stash like commands like show/list. So other users can see who solved what conflict and why that decision was made. I'm using terms like pop/apply/create just to be consistent with stash also. The reason I make that a manual step and not an automatic step like git rerere tends to do, is that existing users of git won't be aware of these automated conflict resolutions and I'm sure many people won't like these being applied automatically by default.

Admittedly I don't use git stash for temporary local changes, I just use commits and branches, amend them, delete them etc. as I see fit. But I think the concept is very similar, these are not complete buildable commits.

But I think you're right Chris if we start from scratch and call it `git conflict` (although I was thinking of maybe `git resolve` or `git re`, since rerere already abbreviates resolution to just re) we don't have to worry about backwards compatibility with existing commands designed for a different purpose like rerere. I'm not too worried about the naming as long as the workflow is easy to use.

I might fly this by my lecturers as a research project. What do you think Chris and Junio? I'd be happy to send you patches of the work in progress as it's going along if you guys would be happy to see them?

Regards,

Eric Curtin

Software Engineer Ovens Campus, Cork, Ireland

Dell EMC