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.

Reply via email to