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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Apr 6, 2023, 10:01 UTC
Message-ID: <cfb0d0f2-dc82-885d-99d6-fa641b5a2923@gmail.com>
In-Reply-To: <4fa6d2da-4885-09d9-dddb-6f19efda6398@gmx.de>

On 05/04/2023 13:07, Johannes Schindelin wrote:

Show 10 quoted lines

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

Show 5 quoted lines

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

Show 27 quoted lines

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