blob: 49a9a7d53f5836ecf2c5bcadb30f0d314414afe0 [file] [log] [blame]
Junio C Hamano1a4e8412005-12-27 08:17:231MERGE STRATEGIES
2----------------
3
Junio C Hamano1aa40d22010-01-21 17:46:434The merge mechanism ('git-merge' and 'git-pull' commands) allows the
5backend 'merge strategies' to be chosen with `-s` option. Some strategies
6can also take their own options, which can be passed by giving `-X<option>`
7arguments to 'git-merge' and/or 'git-pull'.
8
Junio C Hamano1a4e8412005-12-27 08:17:239resolve::
10This can only resolve two heads (i.e. the current branch
Junio C Hamano1de75722009-03-26 08:39:3811and another branch you pulled from) using a 3-way merge
Junio C Hamano1a4e8412005-12-27 08:17:2312algorithm. It tries to carefully detect criss-cross
13merge ambiguities and is considered generally safe and
14fast.
15
16recursive::
Junio C Hamano1de75722009-03-26 08:39:3817This can only resolve two heads using a 3-way merge
18algorithm. When there is more than one common
19ancestor that can be used for 3-way merge, it creates a
Junio C Hamano1a4e8412005-12-27 08:17:2320merged tree of the common ancestors and uses that as
21the reference tree for the 3-way merge. This has been
22reported to result in fewer merge conflicts without
23causing mis-merges by tests done on actual merge commits
24taken from Linux 2.6 kernel development history.
25Additionally this can detect and handle merges involving
26renames. This is the default merge strategy when
27pulling or merging one branch.
Junio C Hamano1aa40d22010-01-21 17:46:4328+
29The 'recursive' strategy can take the following options:
30
31ours;;
32This option forces conflicting hunks to be auto-resolved cleanly by
33favoring 'our' version. Changes from the other tree that do not
34conflict with our side are reflected to the merge result.
Junio C Hamanoa3cfb762012-09-15 05:32:1435For a binary file, the entire contents are taken from our side.
Junio C Hamano1aa40d22010-01-21 17:46:4336+
37This should not be confused with the 'ours' merge strategy, which does not
38even look at what the other tree contains at all. It discards everything
39the other tree did, declaring 'our' history contains all that happened in it.
40
41theirs;;
Junio C Hamanoa3cfb762012-09-15 05:32:1442This is the opposite of 'ours'.
Junio C Hamano1aa40d22010-01-21 17:46:4343
Junio C Hamano39c7a692010-10-27 06:08:5444patience;;
45With this option, 'merge-recursive' spends a little extra time
46to avoid mismerges that sometimes occur due to unimportant
47matching lines (e.g., braces from distinct functions). Use
48this when the branches to be merged have diverged wildly.
49See also linkgit:git-diff[1] `--patience`.
50
Junio C Hamano1575c202013-04-15 20:25:5951diff-algorithm=[patience|minimal|histogram|myers];;
52Tells 'merge-recursive' to use a different diff algorithm, which
53can help avoid mismerges that occur due to unimportant matching
54lines (such as braces from distinct functions). See also
55linkgit:git-diff[1] `--diff-algorithm`.
56
Junio C Hamano39c7a692010-10-27 06:08:5457ignore-space-change;;
58ignore-all-space;;
59ignore-space-at-eol;;
60Treats lines with the indicated type of whitespace change as
61unchanged for the sake of a three-way merge. Whitespace
62changes mixed with other changes to a line are not ignored.
63See also linkgit:git-diff[1] `-b`, `-w`, and
64`--ignore-space-at-eol`.
65+
66* If 'their' version only introduces whitespace changes to a line,
67 'our' version is used;
68* If 'our' version introduces whitespace changes but 'their'
69 version includes a substantial change, 'their' version is used;
70* Otherwise, the merge proceeds in the usual way.
71
Junio C Hamano2db3e752010-09-03 21:33:0672renormalize;;
73This runs a virtual check-out and check-in of all three stages
74of a file when resolving a three-way merge. This option is
75meant to be used when merging branches with different clean
76filters or end-of-line normalization rules. See "Merging
77branches with differing checkin/checkout attributes" in
78linkgit:gitattributes[5] for details.
79
80no-renormalize;;
81Disables the `renormalize` option. This overrides the
82`merge.renormalize` configuration variable.
83
Junio C Hamano39c7a692010-10-27 06:08:5484rename-threshold=<n>;;
85Controls the similarity threshold used for rename detection.
86See also linkgit:git-diff[1] `-M`.
87
Junio C Hamanod2179ef2010-10-22 04:12:1788subtree[=<path>];;
Junio C Hamano1aa40d22010-01-21 17:46:4389This option is a more advanced form of 'subtree' strategy, where
90the strategy makes a guess on how two trees must be shifted to
91match with each other when merging. Instead, the specified path
92is prefixed (or stripped from the beginning) to make the shape of
93two trees to match.
Junio C Hamano1a4e8412005-12-27 08:17:2394
95octopus::
Junio C Hamano1de75722009-03-26 08:39:3896This resolves cases with more than two heads, but refuses to do
97a complex merge that needs manual resolution. It is
Junio C Hamano1a4e8412005-12-27 08:17:2398primarily meant to be used for bundling topic branch
99heads together. This is the default merge strategy when
Junio C Hamano1de75722009-03-26 08:39:38100pulling or merging more than one branch.
Junio C Hamano1a4e8412005-12-27 08:17:23101
102ours::
Junio C Hamanobf984de2009-11-23 06:11:19103This resolves any number of heads, but the resulting tree of the
104merge is always that of the current branch head, effectively
105ignoring all changes from all other branches. It is meant to
Junio C Hamano1a4e8412005-12-27 08:17:23106be used to supersede old development history of side
Junio C Hamano1aa40d22010-01-21 17:46:43107branches. Note that this is different from the -Xours option to
108the 'recursive' merge strategy.
Junio C Hamanoe6c92032008-03-19 09:24:34109
110subtree::
111This is a modified recursive strategy. When merging trees A and
112B, if B corresponds to a subtree of A, B is first adjusted to
113match the tree structure of A, instead of reading the trees at
114the same level. This adjustment is also done to the common
115ancestor tree.