George Spelvin <lkml@xxxxxxx> writes: > 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. I thought that "git rebase -i" allows the todo file (i.e. list of steps still to be performed) to be edited before continuing; would your use case be supported by using that?
