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

[Phillip Wood <phillip.wood123@gmail.com>]

On 05/04/2023 13:07, Johannes Schindelin wrote:
> Hi Oswald,
> 
> please do reply-to-all on this list.
> 
> On Tue, 28 Mar 2023, Oswald Buddenhagen wrote:
> 
>> On Tue, Mar 28, 2023 at 04:53:52PM +0200, Johannes Schindelin wrote:
>>> I do not think that the concept in its
>>> current form mixes well with being in the middle of a `--rebase-merges`
>>> run.

That definitely needs to be addressed, I'd be happy to start with an 
implementation that only rewinds linear history but it must error out if 
it encounters a merge and --rebase-merges was given. I'd also be very 
happy if we could rewind across merges by updating existing labels in 
the new todo list.

> [...] 
> What I need much, much, much more often is a way to redo only _part_ of
> the rebase. Like, the last 3 commits. And not from scratch, oh no! I do
> not want the original commits to be cherry-picked, but the ones that were
> already rebased.

That's what I want most often as well. Oswald's --rewind always rewinds 
to $onto but I think it does use the rebased commits in the new todo 
list. It looks like the new todo list will contain the commits 
$onto..HEAD plus the old todo list

> In other words, I need a nested rebase.

I can see the benefit in being able to checkpoint while rebasing but I'm 
not sure that needs to be tied to rewinding. For example if I'm making a 
change I'm not sure about I'd like to be able to set a checkpoint before 
that change so I can rewind to the previous state. I'd be happy to see 
checkpointing and rewinding added separately.

Best Wishes

Phillip

> Now, why do I keep bringing up this idea of a nested rebase, when such a
> nested rebase would not be able to perform a rewind as you asked?
> 
> The reason is that I am still very much unconvinced that `--rewind` can do
> anything that `git rebase --abort` and starting over cannot do. So: no
> patches required, right?
> 
> However, the use case that _immediately_ comes to mind when you talk about
> these rewinds is when a part of a rebase needs to be redone, in the middle
> of said rebase. And that _does_ require a nested rebase, and the
> `--rewind` would in most cases only throw away too much work.
> 
> Ciao,
> Johannes
> 
> P.S.: Yes, yes, I know, a nested rebase can be simulated via
> 
> 	git worktree add --detach /tmp/throw-away &&
> 	git -C /tmp/throw-away rebase -i HEAD~3 &&
> 	git reset --hard $(git -C /tmp/throw-away rev-parse HEAD) &&
> 	git worktree remove /tmp/throw-away
> 
> but that is of course not only inconvenient, but leaves too much
> book-keeping and safe-guarding up to the human user, e.g. to make sure
> that the `git reset --hard` does not overwrite uncommitted changes/files.
> 
> FWIW I simulate nested rebases in the illustrated way _a lot_.