Hi George, On Tue, 31 Mar 2020, George Spelvin wrote: > Thinking about Philip Oakley's suggestion, it dawned on me that > we can *already* do a nested rebase manually, and having a less > manual alias for the procedure would be reasonable. > > Suppose the last four commits are O-A-B-C, and whether they were created > by this rebase or existed before is irrelevant. > > If I want to rebase --nested -i O, then I --edit-todo and > prepend the following four lines: > reset O > pick A > pick B > pick C > > If a nested rebase command does just that, I think it would cover my > use case. If it adds a comment saying "nested rebase ends here", > it's easy to cancel the nested rebase if there was a mistake. FWIW this is precisely what I do in https://github.com/git-for-windows/build-extra/blob/70d940d1b/ever-green.sh#L184-L246 I create a new worktree (without checking out anything), start a rebase with a custom (fake) editor that simply grabs the todo list and aborts that rebase. Then I remove that worktree and insert the grabbed todo list into the current one. However, I find that it is not at all easy to cancel the nested rebase because the current `HEAD` is recorded _nowhere_. Ciao, Dscho > A slightly fancier thing a nestrd rebase could do is see if any of the > newly created picks are also used in merges that were already in the todo > list. In that case, follow the pick by a label command and update the > later merge to refer to the label. >
