Hi george,

On 31/03/2020 01:00, 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

Maybe `--rework` as a possible alternate option name, if the concept of
it being truly nested process does not work out?

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.

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.