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.
