Re: Feature request: rebase -i inside of rebase -i

> I'm cleaning up a patch series for submission, and came across a fixup in
> patch #4/20 that belongs in #2/20.
>
> Unfortunately, I can't go back two patches to apply the fix until I get to 
> the end of the current rebase, then go back down to clean it up. :-(
>
> Thinking about it, I realized that a rebase in a rebase is a perfectly 
> well defined operation.  *If* you don't bother setting a new abort point 
> (it's not a fully nested transaction), *and* require that the tree be 
> clean (no stashing allowed; create a WIP commit instead), it's just a 
> matter of putting some commits back on the front of the todo-list and 
> checking out the old version.