On Thu, Apr 6, 2023 at 7:03 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
> 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
