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.