What are git's merge strategies? [duplicate]

Question

Possible Duplicate:
When would you use the different git merge strategies?

When git merges files I'm working on, I see:

Merge made by the 'recursive' strategy 

What exactly is the recursive strategy? What other strategies are there (if any)? And what would be the benefit of using one over the other? Do different strategies have different performances? Or could two different strategies result in different merge results?

Answer 1

From git help merge:

   The merge mechanism (git-merge and git-pull commands) allows the    backend merge strategies to be chosen with -s option. Some strategies    can also take their own options, which can be passed by giving    -X<option> arguments to git-merge and/or git-pull.     resolve        This can only resolve two heads (i.e. the current branch and        another branch you pulled from) using a 3-way merge algorithm. It        tries to carefully detect criss-cross merge ambiguities and is        considered generally safe and fast.     recursive        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        mis-merges 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:         ours            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.             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.         theirs            This is opposite of ours.         subtree[=path]            This option is a more advanced form of subtree strategy, where            the strategy makes a guess on how two trees must be shifted to            match with each other when merging. Instead, the specified path            is prefixed (or stripped from the beginning) to make the shape            of two trees to match.     octopus        This resolves cases with more than two heads, but refuses to do a        complex merge that needs manual resolution. It is primarily meant        to be used for bundling topic branch heads together. This is the        default merge strategy when pulling or merging more than one        branch.     ours        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.     subtree        This is a modified recursive strategy. When merging trees A and B,        if B corresponds to a subtree of A, B is first adjusted to match        the tree structure of A, instead of reading the trees at the same        level. This adjustment is also done to the common ancestor tree.