Menu
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?
642
Recursive is the default merge strategy when pulling or merging one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.
You can use git merge-base --all to see the merge base candidate commits. Using -s resolve will pick one of them, while -s recursive will take all of them, merge them into a new commit, and use that new commit as the merge base.
" ours represents the history and theirs is the new applied commits". In a merge, git takes the current branch and apply the additional commits to it's HEAD. The current branch is the history ours and the additional commits are new theirs . In a rebase, git rewrites the history of the current branch.
The merge commit continues to have two parents. Note: There is nothing right or wrong of either one of the strategies but with fast forward merge you have a straight line of history and with the recursive merge, it is of multiple lines.
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(?)
173
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.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
