40

I'm having a bit of a problem. We have our own CMS which is using git for collaboration and versioning and stuff.

Now I have two git repositories A and B, A which is a project and B which is the CMS itself. Now i want to get B into A, but when i do this i get alot of merge-conflicts and the solution for the conflicts is always to use the stuff from B.

Now what I think i need is

git merge <branch> -s recursive theirs <commit>

because I want to merge and when there is a merge conflict it should be forced to use the solution from B. But i can't get it to work. It always keeps telling me fatal: 'theirs' does not point to a commit.

The recursive theirs I found here.

Does anyone know what I do wrong?

florisla
  • 12,668
  • 6
  • 40
  • 47
Daan Poron
  • 2,708
  • 5
  • 29
  • 33
  • Possible duplicate of [How do I select a merge strategy for a git rebase?](http://stackoverflow.com/questions/2945344/how-do-i-select-a-merge-strategy-for-a-git-rebase) – Louis May 27 '16 at 12:45

2 Answers2

78

You must use this form to pass merge strategy options:

git merge -s recursive -Xtheirs # short options
git merge --strategy recursive --strategy-option theirs # long options

Also make sure your version supports -Xtheirs, that's a quite recent feature(?)

Elijah Lynn
  • 12,272
  • 10
  • 61
  • 91
u0b34a0f6ae
  • 48,117
  • 14
  • 92
  • 101
  • it was indeed the wrong git version, now with the new one it works .. only it doesn't work as good as i thought, i get all the merge conflicts but none of them contain any conflicts :s – Daan Poron Feb 16 '10 at 10:37
  • 8
    This answer seems to miss the inclusion of the branch in the merge? `git merge -s recursive -Xtheirs ` – robstarbuck Sep 29 '17 at 09:52
3

I think the reason it's failing is that you are specifying "recursive theirs" as the strategy. "recursive" is a strategy, and when you put a space after it, "theirs" is interpreted as something git needs to merge your working copy with (eg. another branch or refspec).

I think you will not be able to specify a strategy exactly like what you want. There is a strategy called "ours" which is the opposite of what you are wanting.

The usual pattern used in this situation is to either merge or rebase to the "B" repository. From within the "A" repository's working copy, you would do a rebase, if possible (it might not be possible, if you are already sharing the git repo with other developers). A rebase would essentially roll the A repository back to a common commit within both repositories, apply "B" commits, then "A" commits on top. You'd resolve any merge conflicts along the way.

Once you go thru the pain of either merging or rebasing to the "B" repository, the future merges will be less painful.

Jess Bowers
  • 2,846
  • 1
  • 22
  • 42