git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jacob Keller <jacob.keller@gmail.com>
Date
Feb 20, 2018, 22:40 UTC
Message-ID
<CA+P7+xpWi0kekTM3aJ4VnxtVh0DpGb_U2D6=cUCqz0XqvYwJTQ@mail.gmail.com>
In-Reply-To
<20180220205603.GA13721@sigill.intra.peff.net>
On Tue, Feb 20, 2018 at 12:56 PM, Jeff King <peff@peff.net> wrote:
Show 54 quoted lines
> 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

Using a --rewind that simply tracks the point of each history and can reset back to each seems a bit more inline with what the original suggestion is. Sort of like "undo" in an editor might. You could even add a "rewind=x" so it could go back more than one step at a time, tho just re-running rewind until you get where you want would be doable as well.

I like the overall direction of both these suggestions.

Thanks, Jake

Previous: Jeff KingNext: Phillip Wood
Message 7 of 10 in “Is there any way to "interrupt" a rebase?”
  1. Hilco WijbengaFeb 19, 2018
  2. brian m. carlsonFeb 19, 2018
  3. Hilco WijbengaFeb 19, 2018
  4. Johannes SchindelinFeb 20, 2018
  5. Johannes SchindelinFeb 20, 2018
  6. Jeff KingFeb 20, 2018
  7. Jacob KellerFeb 20, 2018
  8. Phillip WoodFeb 23, 2018
  9. Jeff KingFeb 20, 2018
  10. Phillip WoodFeb 20, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.