Re: Is there any way to "interrupt" a rebase?

[Jeff King <peff@peff.net>]

On Tue, Feb 20, 2018 at 12:44:51PM +0100, Johannes Schindelin wrote:

> > It might be even possible to design a new subcommand for the interactive
> > rebase to facilitate a variation of this strategy (possibly even making
> > use of the fact that the interactive rebase accumulates mappings between
> > the original commits and the rewritten ones in
> > $GIT_DIR/rebase-merge/rewritten-list, intended for use in the post-rewrite
> > hook).
> 
> This feature might look somewhat like this:
> 
> 	git rebase --replay-latest-commits 3
> 
> and it would not even have to look at the `rewritten-list`. All it would
> do is to put back the latest `pick` from the `done` file (in case of merge
> conflicts) into the `git-rebase-todo` file, then insert `pick lines for
> HEAD~3.. at the beginning of that todo file, and then `git reset --hard
> HEAD~3`.

Keep in mind that the "pick" lines could be "edit", "squash", etc.

I think the general form of your original email's proposal is something
like: What if we had a "git rebase --rewind" that could "undo" the prior
command? So if I had a todo file like:

  pick 1
  edit 2
  x make test
  edit 3
  x make test
  pick 4

and I failed at the second "make test", then I'd have:

  pick 1
  edit 2
  x make test
  edit 3
  x make test

in the "done" file, with the final pick remaining in "todo". Could I
then ask to "rewind" my state by moving "x make test" back to the
"todo". And two rewinds would get me back to applying patch 3, which I
could then fix up and re-run my test. Or four rewinds would get me back
to patch 2, which maybe is where I made the initial mistake.

That's a bit more primitive than what you're proposing in this
follow-on, because you'd be doing the replay yourself (unless we remap
the commits). But it's very easy to reason about and implement.

Anyway, just musing at this point. I haven't thought it through, but I
like the direction of everything you're saying. ;)

-Peff