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 ;-)
