CODEWITHSUNDEEP
gitgit-merge
OdieO
OdieO

Reputation: 7004

Git merge -X theirs not merging all changes

I've checked out a branch and I want to merge in master. The branch is behind master, since master hasn't been merged with this branch in two weeks, so I want to use all changes from master.

I do the following:

git merge -s recursive -X theirs master

For the most part it merges, but there are at least a couple spots where conflicts didn't from theirs.

For instance, there is one line:

#import "VMVideo_Private.h"

This was taken out from master at some point in the last two weeks but since this branch hasn't been merged in the last two weeks it's still there in the branch.

After the merge using theirs, it's still there.

Furthermore, if I try to merge manually with just a:

git merge master

This particular conflict does not come up at all.

Upvotes: 2

Views: 7271

Answers (2)

zs2020
zs2020

Reputation: 54543

Most of time it is your branches are merged back and force and the root of each diverge points hide the difference. There is a trick to fix it.

Suppose you want to merge from master to your current branch cur, after doing 

git merge -s recursive -X theirs master
git commit

then do (you have to commit first):

git diff --ignore-space-at-eol cur..master | git apply

This simply compares the merged cur and master branches, and the diff will be picked up and applied as a patch.

Upvotes: 3

torek
torek

Reputation: 489708

In the recursive merge strategy, -X theirs (or for that matter -X ours) simply means that in the case of conflicts it should automatically resolve the conflict by choosing "their version" (or "our version", with -X ours).

If there is no conflict, your -X selection does not come into play at all.

For instance, suppose that in the original (common merge-base) version, file foo.txt, line 34, said Rumplestiltskin. Suppose further that you changed this to George Clooney. And, finally, suppose that file foo.txt was in fact changed in master, but nowhere near line 34. Now you ask git to merge their (master's) changes with yours: it keeps your change, where Rumplestiltskin becomes Clooney, as there is no conflict with their changes, where foo.txt now claims to be true instead of false. The resulting merge now makes claims (which it claims are true) about Mr Clooney, rather than about a fairy-tale character.

(In some cases, git—which is just doing a diff of the various versions—will decide that the changes you and they made to some code (or text) is best represented by something that, semantically, is quite meaningless. For C and Java code, for instance, it may falsely synchronize on lines with nothing but a close-brace. The resulting merges can be hilariously, or tragically, bad. Sometimes choosing a modified diff algorithm, e.g., "patience diff", can help. Sometimes nothing helps.)

Upvotes: 4

Related Questions