Philip Oakley wrote:
> 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'.
There is a `contrib/rerere-train.sh` script in git's repository,
that can recreate rerere resolutions from existing merge commits.
Extending the options Eric outlined, a collaborative conflict
resolution workflow might thus be:
* 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)
The last discussion on rerere-train.sh on this list was here:
https://lore.kernel.org/git/BZAQIE4YND2I.Z7BFCW7BLH3K@penguin/
