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

[George Spelvin <lkml@SDF.ORG>]

I'm just trying to make the point that guardrails on "git rebase
--nested" which don't exist on the more powerful and dangerous "git
rebase --edit-todo" are a case of installing a high-security lock on a
screen door.

If you can come up with something that works for both, then great. But 
going to significant trouble (especially in terms of design complexity and 
legacy burden; I'm not worrying about SMOP) for a special-case solution 
that only works for one is a waste of effort.

Both, or neither.  Just one is bad design.

Regarding the semantics, consider the following case:

* Initial branch history is O-A-B-C-D
* I initially "git rebase A"
* Then realize that I made a mistake and "git rebase --nested A^"
* I reverse the order of the commits to D-C-B-A
* The rebase continues, and I successfully pick D and C.
   (remaining commands are "pick B" and "pick A"
* Then I "git rebase --abort".

What state should I expect to be returned to?

(Without separately abortable nested rebases, the state after the nested
rebase is exactly the same as if I'd used "git rebase A^" in the first
place, which doesn't seem like a terribly bad thing.)