Definition of recursive merge strategy pulled from the git merge documentation.
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
The recursive strategy can take the following options:
As stated, the recursive strategy, which is the default strategy, makes use of the 3-way recursive merge algorithm (explained here and on Wikipedia).
My understanding is that conflicting hunks must be manually resolved and they are typically represented like this
<<<<<<<<<<<
developer 1's code here
============
developer 2's code here
>>>>>>>>>>>
The ours option of the recursive merge strategy is documented as follows:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.
Now suppose I have the heads of two branches Y and M, with a common base ancestor B as follows
When merging Y and M using the default recursive strategy, line 30 will become Print("hello"); since at line 30, Y represents a change from the base ancestor and M does not. But if I were on branch M and run
git merge -s recursive -X ours Y
will line 30 become Print("bye"); in the merged output?
To those of you who say that this is obvious, note that the ours option states
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version.
But (as I understand) there is no conflicting hunk at line 30.
For completeness, I will also give the documentation of the theirs option:
This is the opposite of ours.
The documentation for the ours strategy is as follows:
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.
So returning to the example above, if I ran
git merge -s ours Y
on branch M, it is clear that line 30 will be Print("bye"); in the merged output. In this case, why is there also not a theirs strategy? How can I achieve behaviour equal and opposite to the ours strategy?
I'm asking because I'm working on a project where I want to regularly and completely overwrite the master branch with changes from another development branch, whenever the code on the development branch builds successfully. This way I can ensure that my development branch never drifts too far off from the master branch and also that the code on the master branch will build successfully.
I have seen this question which recommends the solution
git checkout dev-branch
git merge -s ours master
But Git simply outputs Already up-to-date, despite the fact that the two branches contain different code (and dev-branch is actually a few commits ahead of master).
My current solution is to do
git merge -s recursive -X theirs dev-branch
I have also seen this question which recommends using the theirs option of the recursive strategy. But as the ours option of the recursive strategy is clearly different ours strategy, so too would the theirs option of the recursive strategy be different from the theirs strategy that I'm talking about.
See Question&Answers more detail:
os 
