Re: Current state / standard advice for rebasing merges without information loss/re-entry?

[Philip Oakley <philipoakley@iee.email>]

On 18/04/2022 16:48, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> The rerere man page is still magic for me. The UX here could be
>> improved. (also, could the rerere-train be focussed on each merge?)
> I am curious to see a clarification on the question in parentheses.
>
It was the feeling that the rerere-train currently (IIRC) will parse a
whole set of commits & merges to create the rerere database and then try
an apply all the potential resolutions when called upon.

Thus for the 'replay' scenario, it could be that the database is
partitioned and prioritised so that first it applies the resolutions for
that particular merge, then considers previous resolutions, and finally
starts using resolutions that occur later in the series being rebased.

There is also the possibility that the rerere database is updated after
each commit resolution (and especially as merges pass by) so that the
'prior' resolutions are up to date with any of the current semantic
changes, rather than being outdated so could be applied first (i.e. two
rerere changes being applied to the merge..).

So, essentially, it's talking a small part of the rerere-train at each
step in the replay, so that it's more focussed.

Philip

(this all assumes my mental model of the rerere magic is roughly correct ;-)