On 19/02/18 19:35, Hilco Wijbenga wrote: > > Hi all, > > When maintaining a long running branch, I regularly rebase onto our > active development branch so that my branch stays up-to-date. What > happens fairly often is that during such a rebase, Git will exit > because of rebase/merge conflicts. Nothing unexpected there, of > course, but as it sometimes turns out, the conflict should have been > fixed in an earlier commit. The only way that I know of to fix this, > is to abort the rebase and start over with "git rebase ... > --interactive" then "edit" every commit and go through them > one-by-one. This is often overkill, though. Is there a better way? > Perhaps I could "rewind" the rebase to an earlier commit and restart > from there? > > 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")? > > (Surely, it's not as simple as doing a "git reset --hard > sha-of-commit-C" is it?)
Hi Hilco In the past when I've wanted to edit the commit directly rather than create a fixup I've done something like git log --pretty="pick %h %s" C.. git rebase --edit-todo <paste the output of git log into the editor> git checkout C <amend this commit> git commit --amend git rebase --continue Best Wishes Phillip > Cheers, > Hilco >
