The problem: during an interactive rebase, the user might realize that they want to redo (part of) the rebase, e.g. to resolve merge conflicts in a different way, say, by re-picking the latest three commits. Usually one would do git rebase -i HEAD~3, but that does not work because we are already in a rebase.
What I typically do is to create a throw-away worktree with git worktree add --detach, call git rebase -i HEAD~3 in that worktree, then copy the output of git rev-parse HEAD, then remove the worktree, and call git reset --hard <commit> in the original worktree.
That is fraught with danger, though, and very inconvenient.
The proposed solution: a new git rebase -i --nested [...] option. The --nested option would allow
This would generate the todo list as usual, but then prepend it to the current todo list. At the end, it would insert a new command that indicates that the nested rebase is now complete, and at the same time provides enough information to allow git rebase --abort to abort the nested rebase.
Some care will have to be taken in case of combining --nested with --rebase-merges: that will potentially override the onto label. In that instance, at the end of the nested rebase we would have to re-set the onto label to the original value.
It is not yet possible to call label <name> <commit>, only label <name>. We would have to introduce the former form to make it possible to re-set the onto label. Or use reset <commit> and then label <name>, but that is somewhat ugly.
The problem: during an interactive rebase, the user might realize that they want to redo (part of) the rebase, e.g. to resolve merge conflicts in a different way, say, by re-picking the latest three commits. Usually one would do
git rebase -i HEAD~3, but that does not work because we are already in a rebase.What I typically do is to create a throw-away worktree with
git worktree add --detach, callgit rebase -i HEAD~3in that worktree, then copy the output ofgit rev-parse HEAD, then remove the worktree, and callgit reset --hard <commit>in the original worktree.That is fraught with danger, though, and very inconvenient.
The proposed solution: a new
git rebase -i --nested [...]option. The--nestedoption would allowThis would generate the todo list as usual, but then prepend it to the current todo list. At the end, it would insert a new command that indicates that the nested rebase is now complete, and at the same time provides enough information to allow
git rebase --abortto abort the nested rebase.Some care will have to be taken in case of combining
--nestedwith--rebase-merges: that will potentially override theontolabel. In that instance, at the end of the nested rebase we would have to re-set theontolabel to the original value.It is not yet possible to call
label <name> <commit>, onlylabel <name>. We would have to introduce the former form to make it possible to re-set theontolabel. Or usereset <commit>and thenlabel <name>, but that is somewhat ugly.