On Mon, Feb 19, 2018 at 2:36 PM, brian m. carlson <sand...@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.
