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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 20, 2018, 11:03 UTC
Message-ID: <nycvar.QRO.7.76.6.1802201147300.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <CAE1pOi070p9VNPnLS3jSXp7TrbR2fhOc7sx+58exAp92k4D0dw@mail.gmail.com>

Hi Hilco,

On Mon, 19 Feb 2018, Hilco Wijbenga wrote:

Show 35 quoted lines

> On Mon, Feb 19, 2018 at 2:36 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > On Mon, Feb 19, 2018 at 11:35:25AM -0800, Hilco Wijbenga wrote:
> >> So a scenario like this:
> >>
> >> my-branch : X -> A -> B -> C -> D -> E -> F -> G
> >> base-branch : X -> Y
> >>
> >> git rebase --onto base-branch HEAD~7
> >> commit A --> conflicts
> >> ... lots of work ...
> >> commit B --> conflicts
> >> ... lots of work ...
> >> commit C (Git handles conflicts)
> >> commit D (no conflict)
> >> commit E --> conflicts
> >> ... er, that should have been fixed in commit C
> >>
> >> How do I keep all the work I did for commits A and B? I get the
> >> impression that rerere does not help here because I did not finish the
> >> rebase succesfully (and that makes perfect sense, of course). Is there
> >> a way at this point in the rebase to "go back" to commit C (so without
> >> "git rebase --abort")?
> >
> > What I do in this case is I unstage all the changes from the index, make
> > the change that should have gone into commit C, use git commit --fixup
> > (or --squash), and then restage the rest of the changes and continue
> > with the rebase.  I can then use git rebase -i --autosquash afterwards
> > to insert the commit into the right place.
> 
> Yes, that's essentially what I end up doing too. Obviously, in cases
> like this, Murphy likes to drop by so commit D will have made changes
> to the same files as commit C and you can't cleanly move the fix-up
> commit to commit C. :-( I had hoped there might be an easier/cleaner
> way to do it.

I am a heavy user of interactive rebase. Which is unsurprising, given that I implemented the first version of it.

And I find myself in the same situation quite often (as of recent, more often when doing complicated rebases involving non-linear commit topologies, but I digress).

Being that familiar with the internals of the interactive rebase command gives me the opportunity to do "clever" things.

My number one strategy is to mix interactive rebase with cherry-pick: I `git reset --hard HEAD^` (which refers to the rewritten C), fix up the commit as intended, then look at the latest interactive rebase command listed in the output of `git status`, then determine the commit range of commits I want to replay on top and then call `git cherry-pick <range>` (in your case, that would be `git cherry-pick C..E`.

Admittedly, this strategy is a bit cumbersome because a lot of book-keeping is performed by my working memory instead of Git.

When I am particularly tired and overworked (and therefore know that my working memory is less useful than usual), I therefore resort to my second-favorite strategy: U use the `done` file.

I literally copy parts of $GIT_DIR/rebase-merge/done to the beginning of $GIT_DIR/rebase-merge/git-rebase-todo (the most convenient way to open the latter is `git rebase --edit-todo`). In your case, those would be the `pick` lines cherry-picking D and E. Then, as before, `git reset --hard <commit>` (where I look up the `<commit>` using an aliased version of `git log --graph --oneline --left-right --boundary`), amend the commit, and then `git rebase --continue`.

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).

Ciao, Johannes