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