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

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Apr 7, 2023, 07:00 UTC
Message-ID: <ZC+/nYp2RRF9Gjrd@ugly>
In-Reply-To: <CAMP44s13z=hZHzU+EB7qBZnqQcmRGe4aknF=wocOK9uh6NHbcA@mail.gmail.com>

On Thu, Apr 06, 2023 at 07:21:39PM -0500, Felipe Contreras wrote:

Show 7 quoted lines

>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.