Hi all, On 28/03/2020 14:25, Johannes Schindelin wrote: > Hi George, > > On Thu, 26 Mar 2020, George Spelvin wrote: > >> On Wed, Mar 25, 2020 at 08:26:48PM +0100, Johannes Schindelin wrote: >>> On Sat, 21 Mar 2020, George Spelvin wrote: >>>> My assumption has been that, for simplicity, there would only be one >>>> commit in progress, and aborting it aborts everything. >>> But that does not necessarily make sense. Imagine that you rebase the >>> latest three commits, interactively. Then a merge conflict in the third >>> makes you realize that the first commit is no longer needed. >>> >>> Enter the nested rebase. You manually re-schedule the failed `pick` via >>> `git rebase --edit-todo` and then run the nested rebase: `git reset --hard >>> && git rebase -i --nested HEAD~2`. >>> >>> Except that you made a typo and said `HEAD~3` instead of `HEAD~2`. You >>> delete the entire todo list to get a chance to restart the nested rebase. >>> >>> But now the entire rebase gets aborted? >> Um, this example is not persuasive. If I just leave the excess commit at >> the front of the to-do list, then it will be recreated without change. > There are _many_ ways to mess up a nested rebase, including (but not > limited to) `--onto`, forgetting `-r`, editing the todo list too much in > an editor without undo. > > If you are suggesting that a nested `git rebase -i` would not need a way > to abort _just_ the nested rebase, then I fear we must stop the > conversation right here. That's not going to fly. > >> (Note that if I choose too *small* a nubmer by accident, I can insert a >> "break" at the front of the list and then rebase --nested starting from >> there.) > There are many ways how a savvy user would be able to work around the > absence of a proper way to abort a nested rebase. The common theme for all > of those is: > > - they are all quite involved and require knowledge of internals > > - they won't change the fact that it would be seriously negligent for us > to _not_ offer a way to abort nested rebases. > Perhaps we can go the other way on this one. I'd agree that attempting to nest (misunderstood mistaken) rebases is digging a too deep hole that we'd not get out of. However we do have other rebases available, specifically the "rebasing merges" https://git-scm.com/docs/git-rebase#_rebasing_merges. I know rebasing merges is way down the man page, but it has all the power and flexibility needed _if_ we can step across from the mistaken rebase step (we are at the command prompt aren't we?) into the rebasing merge mode. This will require a little bit of expansion of the insn (instruction) sheet so as to _include commented lines of the rebase steps completed_ so far, along with the labels, resets, merges, etc, so that the user can _see_ where they they are within their failed progress (along with a title line telling them their initial command and that they are now on a rebasing merge insn;-). >From there they can update the insn to reset back to the correct point, redo the correct picks, and then get back to their remaining rebase steps. It's a thought anyway. HTH Philip
