From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mon, 07 Mar 2022 16:56:22 GMT
Subject: Re: rewinding interactive rebases
Message-ID: <nycvar.QRO.7.76.6.2203071745590.11118@tvgsbejvaqbjf.bet>
In-Reply-To: <CA+JQ7M-+kq1MTh+DG+HCmXkpsF5Esm_0V=4=2_DS2_ZYdjP2+g@mail.gmail.com>

Hi Erik & Oswald,

it's not really obvious from the text quoted below what is being discussed
here, so let me simply top-post some thoughts:

Problem statement: in the middle of an interactive rebase, the user would
like to choose a different rebase target, without having to abort the
rebase.

Suggested approach: implement support for `git rebase -i --nested --onto
<commit> <base-commit>`, i.e. a `--nested` option.

The idea here is to generate a todo list (just like a fresh `git rebase -i
--onto <commit> <base-commit>` would have done) and _prepend_ it to the
current todo list.

To support a nested `git rebase --abort`, we would probably want to insert
some marker after the newly-generated todo list (maybe a
specially-formatted comment such as `## END NESTED ##`).

To support nested `git rebase --rebase-merges`, we would need to populate
`state.labels` by reading `$GIT_DIR/rebase-merge/refs-to-delete` first
thing when generating the todo list.

For good measure, we should probably populate `state.commit2label` with
this list, too, looking up the respective OIDs via
`refs/rewritten/<label>`.

I realize that this is quite dense information for anybody unfamiliar with
the `sequencer.c` code, and that the idea is _not_ fully fleshed out, but
I lack the time to implement it and wanted to get even just a
half-finished idea out there.

Ciao,
Johannes

On Tue, 1 Mar 2022, Erik Cervin Edin wrote:

> On Tue, Mar 1, 2022 at 1:21 AM Oswald Buddenhagen
> <oswald.buddenhagen@gmx.de> wrote:
>
> > On Mon, Feb 28, 2022 at 10:32:16PM +0100, Erik Cervin Edin wrote:
> > >What's the connection to the original thread [...]?
> > >
> > that depends on what you want to interpret into the original thread,
> > given that a bunch of use cases and solutions were mentioned. my
> > solution is actually functionally identical to one of the later
> > subthreads, as i found after the fact.
>
> Sorry but it's a long thread and at least I am unsure which parts you
> are referring to and how your script fits into that.
>
> > >Maybe you could explain it a bit in the context of the problem.
> > >
> > there really isn't much to it. the git log + git reset are the essence.
> > just run it in the middle of an interactive rebase to see yourself.
>
> Could you elaborate on the intended/usual flow here?
> Rebase => Get conflict => Fix conflict => run the script => ..??
>