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