Re: Is there any way to "interrupt" a rebase?
- From
- Hilco Wijbenga <hilco.wijbenga@gmail.com>
- Date
- Feb 19, 2018, 23:09 UTC
- Message-ID
- <CAE1pOi070p9VNPnLS3jSXp7TrbR2fhOc7sx+58exAp92k4D0dw@mail.gmail.com>
- In-Reply-To
- <20180219223653.GE6619@genre.crustytoothpaste.net>
On Mon, Feb 19, 2018 at 2:36 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:
Show 27 quoted lines
> 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.