git - Same file added by both branches causes weird merge conflict

Question

I currently have two branches I am working on. Because of a software update I had to completly change the folder structre. Therefore I moves the files in both branches. Now I reached a point where I want to merge my working branch into my master branch.

The problem is that there are merge conflicts that tell me that a file was added by only one branch (added by them or added by us). The problem is that the file has been added by both branches.

For example I have a texture at textures/texture1.png. The master branch just moved it to the right location (was before misc/textures/texture1.png). The working branch moved it to the exact same location and edited it afterwards. The merge conflict for this file says:

    added by us: textures/texture1.png

The point is that this is not the file I want! I want the file from the other branch!
When I do

git checkout --theirs textures/texture1.png

I get

error: path 'textures/texture1.png' does not have their veresion

But this file does exist! I added it recently! And that's the file I want

How do I resolve these conflicts?

(more information if needed!)

Side note: git can't quite tell that you both renamed the file, and then you (but not they) edited the file, as git does dynamic rename detection and it's not quite up to the task here. I have not experimented with separating the "rename file" commit from the "modify renamed file" commit vs having them together, but I believe having them separate would give git more chances to "figure things out" as it were. It would particularly help with the "helper branch" technique @mnagel described. — torek, Jul 14 '13 at 23:17

score 17 · Answer 1 · answered Jul 14 '13 at 14:16

17

You can always try

git mergetool

this will open a GUI, where you can choose your desired changes by just clicking the appropriate links. Sometimes you need to do manual changes. But in your case you just have to select a file image.

answered Jul 14 '13 at 14:16

maximus ツ

7,949
3
25
54

1

This does not help Since it just tells me the same (That one branch deleted a file. But it did **not**!) – BrainStone Jul 14 '13 at 14:35

score 10 · Answer 2 · answered Jan 11 '15 at 02:26

While resolving conflicts just use git checkout indicating the right tree-ish (branch name, tag, sha1 of the commit...) from where you want to get a file:

git checkout theirBranchYouAreMerging -- textures/texture1.png

If you don't want all "their" changes, you could then cancel them partially. For that you would need git reset -p for selectively removing any undesirable change from the index, and then git checkout to remove them from the working directory as well:

git checkout theirBranch -- some/file.txt
git reset -p -- some/file.txt
git checkout -- some/file.txt

score 8 · Accepted Answer · answered Jul 14 '13 at 15:14

8

a--b--c--M--d--f--E--g--h--i  <<< master
    \
     \
      x--M'--y--z              <<< you

does your situation looks somewhat like above (where M and M' are the commits moving and E is the commit that edits the textures)? you try to merge z/i and git is not really happy.

you might try to merge M with M' on a temporary branch

a--b--c---M--d--f--E--g--h--i  <<< master
    \      \
     \      X                  <<< helper
      \    /
       x--M'--y--z             <<< you

and then merge helper ("X") with you ("z") and master ("i").

a--b--c---M--d--f--E--g--h--i     <<< master
    \      \                 \ 
     \      X-----XX---------XXX  <<< helper
      \    /      /
       x--M'--y--z                <<< you

that way conflicts are resolved directly after they are created and not carried along. often this is easier because conflicts tend to grow over time.

answered Jul 14 '13 at 15:14

mnagel

6,729
4
31
66

The point is that E is in the branch "you". But I will try this. And with your method I just merge XXX Into master? Because that's where I want the final merge to be. – BrainStone Jul 14 '13 at 17:32
1

it is not really important on what branch E is. the important thing is to do the merge early and have an easier conflict resolution that way (no guarantee that it actually works). when you have a state as depicted in the third graph, you can fast-forward master to helper/XXX without conflicts, as XXX is a successor of i. – mnagel Jul 15 '13 at 07:08
1

This worked for me! Thanks for helping a noob. The network history on GitHub looks funny though but that's ok ;) – BrainStone Jul 15 '13 at 16:30

git - Same file added by both branches causes weird merge conflict

3 Answers3