From: Phillip Wood Date: Thu, 06 Apr 2023 10:01:27 GMT Subject: Re: [RFC PATCH] rebase: implement --rewind Message-ID: In-Reply-To: <4fa6d2da-4885-09d9-dddb-6f19efda6398@gmx.de> 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_.