Re: [RFC PATCH] rebase: implement --rewind

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Thu, Apr 06, 2023 at 07:21:39PM -0500, Felipe Contreras wrote:
>Imagine there was a rebase log for each branch, then `git rebase`
>could use that information to redo a previous rebase, even if that
>rebase was aborted. To restart your current rebase you could do `git
>rebase -i --redo 1` (1 being the previous one). If in the middle of
>that you decide actually your original approach was better, you just
>freely abort, and do `git rebase -i --redo 2`.
>
what exactly would you save to that log?
what comes to my mind is the todo file produced by my --rewind before 
the user edits it: the already rewritten commits (which can of course be 
saved as a single ref), and the remaining todo.
that would make it very much the same thing as the checkpoints phillip 
postulated and i expanded upon.

one difference to what i envisaged would be that one could easily resume 
a rebase one erroneously discarded entirely.

>Wouldn't that solve all the problems?
>
it would, but not necessarily optimally.

consider that after the initial implementation phase, my working branch 
is most of the time inside a 'reshape' (rebase -i --keep-base), and 
since i wrote the initial version of rewind, i initiate new reshapes 
much less often. i basically move freely between the commits in the 
branch.
inserting an additional step of aborting prior to redoing feels just 
clumsy.
at this point i'm actually thinking in the opposite direction: introduce 
commands that let me move by a few commits without even opening the todo 
editor (where have i seen that already? jj?).

the second aspect is performance/resource usage.
the intermediate abort would potentially touch a lot of files each time.  
that costs ssd life and often unneeded recompiles.
and given johannes' use case with *many* merges, rebasing from scratch 
would waste *quite* some time. as i pointed out in the other mail, my 
approach currently suffers from that as well, but it would be rather 
easy to sidestep it. your approach otoh would definitely need a 
fundamental improvement to the skipping algo (*).

(*) this of course sounds like a good idea regardless, but it's not 
necessarily wise to bet on it. i think the problem here is that redoing 
merges is *expected* to be "lossy". if they were marked for replay as 
proposed in https://github.com/gitgitgadget/git/pull/1491 , one could 
also just skip over them.