How do I use git rebase -i after git merge without messing things up?

Question

I have the following situation:

1. I made some commits to my local repository, and then a huge merge of another branch (~150 commits) into the master. It had a lot of conflicts in it.

2. Now, I want to move a commit I made before the merge to be after it before pushing.

Normally, I would use rebase -i for it.

Unfortunately, the default behavior is to break the one-merge-commit I did that actually added 150 more commits to master into separate commits (I understand it's like if I were to use rebase instead of merge to begin with)—which is bad behavior for me for several reasons.

I was very happy to discover the -p flag for rebase, which preserves merges. Unfortunately, this actually applied the same merge again and forgot all about my hard work in conflict resolving. Again—bad behavior!

Is there a solution for what I want? Using rebase -i after merge to re-order or edit specific commits without having to repeat my post-merge operations?

Thanks!

Answer 1

Here's what the rerere-train.sh script I mentioned in my comment does—essentially it redoes the merge, uses your resolution, and just lets rerere see it. You could do this manually just for your single commit if you like:

git checkout <parent of merge commit>
git merge <merged commit>         # if this goes cleanly, we're done
git rerere                        # done automatically if rerere.enabled is true
git checkout <merge commit> -- .  # check out the files from the result of the merge
git rerere                        # done automatically if rerere.enabled is true
git reset --hard                  # wipe away the merge

# and you'd want to follow with git checkout <branch> to return to where you were

But you could also just set rerere.enabled to true, and do those steps minus the direct calls to git rerere—and you'd be set in the future, with rerere automatically being run whenever you resolve conflicts. This is what I do—it's awesome.

If you want to run the script directly, you'll probably want to run it with arguments like rerere-train.sh ^<commit before the merge> <current branch>. (The ^commit notation means "don't walk past this into the history", so it won't bother doing this for all the merge commits in your repo.)

However you get rerere to do its thing, you should end up with the desired resolution recorded. That means you can go ahead and do your rebase -i, and when you run into the conflict, rerere will REuse the REcorded REsolution. Just a heads-up: it still leaves the files marked as conflicted in the index, so that you can inspect them and make sure that what it did makes sense. Once you do, use git add to check them in as if you'd resolved the conflicts yourself, and go on as usual!

The git-rerere manpage contains a very nice, lengthy description of normal use of rerere, which doesn't ever involve actually calling rerere—it's all done automatically. And a note it doesn't emphasize: it's all based on conflict hunks, so it can reuse a resolution even if the conflict ends up in a completely different place, as long as it's still the same textual conflict.