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.
