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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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.
>
> fundamentally, it shouldn't pose a problem: the already done part leads up to
> a single commit, from which a complete todo with merges up to that point can
> be built again, while the remainder of the pre-existing todo should be unfazed
> by the fact that you're repeatedly messing with whatever branch you stopped
> in.

I guess the most important question is: What problem is the proposed
`--rewind` option supposed to solve?

If the idea is to let the user re-start the rebase (for whatever reason),
throwing away the current state, then the proposed code really does not
handle the `--rebase-merges` case at all. Instead, it would implicitly
restart the rebase with `--no-rebase-merges`, i.e. the opposite of what
the user asked for.

But a more important concern is: Is this `--rewind` idea even a good one?
This question brings me back to the initial question: What problem do we
try to solve here? (This is a question that try as I might, I cannot see
answered in the proposed commit message.)

Since I do not want to speculate about your motivation, let me explain the
challenges I would like to see addressed with those rewound-or-nested
rebases.

I frequently find myself in _large_ rebases (we're talking about several
thousand commits, with some 100-200 merge commits), where I notice in the
middle that I should have resolved a previous merge conflict in a
different way.

Do I want to start over and redo the whole rebase? Sometimes I do, and
`git rebase --abort` and the Bash history (Ctrl+R -i will get me back to
the start of the interactive rebase) are my friend. No `--rewind`
required. (Which makes me wonder why that same strategy is not good enough
for your scenarios, too.)

However, that's what I need only in a few, rare instances.

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.

In other words, I need a nested rebase.

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