This is basically the result of a massive class C on the master having been refactored down the line into two smaller classes, C1 and C2. C was then made a subclass of C2 and cut down to a skeletal version for backward compatibility. So from that point on, master contained C, C1 and C2. On that master commit git said C was renamed to C1. The branch was last updated before this happened. (All C++ code, if it helps to visualize the files involved)
Obviously, when I tried a rebase of the branch onto master, there were conflicts that needed to be resolved.
As usual, I used mergetool.
So now the mergetool comes up with the following: On Local, I have the skeletal version of C. Base and Remote have a bunch of changes to C.
Because the skeletal version of C exists on Local, I conclude that the changes from Base and Remote should actually go into C1, leaving C alone.
My question is, how do I do this?
May be on this rebase instance, a more direct resolution of the merge conflict is in order:
git checkout --ours C
git show :1:/path/to/C # check what need to be copied to C1 from Base
git show :3:/path/to/C # check what need to be copied to C1 from remote
git add /path/to/C
git add /path/to/C1
git commit