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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 7, 2023, 00:21 UTC
Message-ID: <CAMP44s13z=hZHzU+EB7qBZnqQcmRGe4aknF=wocOK9uh6NHbcA@mail.gmail.com>
In-Reply-To: <230406.86zg7ls2jx.gmgdl@evledraar.gmail.com>

On Thu, Apr 6, 2023 at 7:03 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> On Wed, Apr 05 2023, Oswald Buddenhagen wrote:

> Right now I do this sort of thing manually, i.e. note the SHA-1's I've
> got so far, --abort at 5/10, then start a rebase for all 10 again, but
> manually replace the SHA-1's for 1-5 with the ones I had already.

Couldn't this be considered a rerebase?

This is what I do most of the time, except I don't even bother saving and replacing the SHA-1s, rerere reapplies my fixes so it's straightforward to reach the desired state.

> Which, I suppose I could also do the other way around, i.e. at 5/10 I'd
> --edit-todo, wipe away 6/10, "finish" my rebase, then use "git rebase
> --onto" later when I'm done to transplant the remaining 6-10/10 on the
> 1-5/5 I'm now happy with.

With this approach the reflog wouldn't be an accurate representation of what happened.

Most of the times I do a rebase I want to see the difference with the previous state of the branch, so I do `git diff @{1}`, but this won't work with this frankensteinian rebase which in true is comprised of multiple subrebases.

Show 8 quoted lines

> But here's the important bit: Sometimes I'm just wrong about my re-edit
> to 2/10 being the right thing, and it would actually just make things
> worse, as I might discover in my "nested" rebase once I'm at 4/5 or
> whatever.
>
> So being able to do an "--abort" ot that point to go back to the
> "un-nested" 5/10 (*not* "original" 5/10) and proceed from there would be
> nice.

Yes, this is something I often desire.

But I feel you guys are overcomplicating the problem.

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

Wouldn't that solve all the problems?

The complication comes in trying to do that without the concept of rebase history.

Cheers.

-- 
Felipe Contreras