git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Philip Oakley <philipoakley@iee.email>
Date
Apr 18, 2022, 16:28 UTC
Message-ID
<ba1ea459-5981-5972-36e6-913eb19c34b4@iee.email>
In-Reply-To
<xmqqczhe1jgp.fsf@gitster.g>
On 18/04/2022 16:48, Junio C Hamano wrote:
Show 6 quoted lines
> 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 ;-)
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 14 in “Current state / standard advice for rebasing merges without information loss/re-entry?”
  1. Tao KlerksApr 18, 2022
  2. Philip OakleyApr 18, 2022
  3. Junio C HamanoApr 18, 2022
  4. Philip OakleyApr 18, 2022
  5. Junio C HamanoApr 18, 2022
  6. Martin von ZweigbergkApr 19, 2022
  7. Junio C HamanoApr 20, 2022
  8. Martin von ZweigbergkApr 20, 2022
  9. Sergey OrganovApr 18, 2022
  10. Martin von ZweigbergkApr 19, 2022
  11. Sergey OrganovApr 19, 2022
  12. Martin von ZweigbergkApr 19, 2022
  13. Tao KlerksApr 19, 2022
  14. Martin von ZweigbergkApr 19, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.