Hi all, What is your problem actually ? You want to edit a commit before where you are in a rebase ? O --- A --- B --- C --- D * You are in a middle of a rebase at commit C. * You want to edit A without finishing all your actual rebase. Is that right ? Then, why making a whole new rebase for that operation ? In this example, you are finally editing A with some sort of new nested operation. This operation should not do anything else than this. Like something atomical, you edit the commit / add a commit / remove one, and that's all. End of the story. Back to the original rebase, and back to commit C. If that "nested" operation made conflict with B, we can move the actual rebase to B to clean the mess you made with the "nested" operation. But you are still in only one rebase. If you abort, everything gets cleaned up. I don't know if any of this is pertinent / understandable, but I hope it gave a fresh view on that. You guys are maybe a bit too focused on what to do in case of an abort of a nested rebase. However, we don't actually know if a nested rebase is the best solution for this job. My two cents
