views:

37

answers:

1

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?

+4  A: 

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
VonC
It might also be an option to use the `--conflict=diff3` option to get all of the hunks in the actual files, I think. (+1)
Jefromi
Thank you! This is exactly what I was after.
carleeto