Re: Collaborative conflict resolution feature request

> On 15/06/2020 10:51, Sergey Organov wrote:
>> Philip Oakley <philipoakley@iee.email> writes:
>>
>>
>> [...]
>>
>>> Also look at 'rerere'.
>> 'rerere' is a superb feature, but isn't it local? If so, how could it
>> help for collaboration? What's the idea? Is there a way to share
>> 'rerere'?
> I saw this (rerere) is two parts. First was to ensure Eric was aware of
> it as a possible capability for use by the 'merge manager', and others,
> so that they didn't loose sight of their conflict resolutions for the
> time when the 'big merge window' came around. E.g. So a dev could do a
> local fix based on their rerere database and then send a patch to the
> merge manager indication their approach to the resolution.
>
> Meanwhile, second, at the moment the rerere database is 'local', mainly,
> as I understand it because of the number of context lines a local user
> has chosen (hence not immediately portable).
>
> I personally believe that it should be possible to some how exchange
> resolutions without that pre-optimisation of the context line choice. I
> had a look back at the old rerere script and that had small fingerprints
> of each resolution stored in the database (at least as I read it).
> However when I look at the modern rerere database it looks like it has
> full pre & post images, rather than just the conflicts, so I'm not yet
> sure what's really happening (i.e. I haven't dived into the c code).
>
> A possibly more sensible approach (to exchanging resolutions) is simply
> to do the merge, without commit, then save that merge as if it's a
> single side commit (with the other merge parent listed in the commit
> message), and that commit can then be pushed/pulled etc and a variant of
> `rerere train` can be used to recreate the local database. In a sense
> the fake merge (why not a proper merge) is a variant of a stash where
> you aren't wanting to pollute the branch trees with this extra 'flotsam'.