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@xxxxxx> 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 => ..?? >
