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