]>
Commit | Line | Data |
---|---|---|
bb73d73c JL |
1 | MERGE STRATEGIES |
2 | ---------------- | |
3 | ||
3c3e6f56 | 4 | The merge mechanism (`git merge` and `git pull` commands) allows the |
566c5111 JH |
5 | backend 'merge strategies' to be chosen with `-s` option. Some strategies |
6 | can also take their own options, which can be passed by giving `-X<option>` | |
3c3e6f56 | 7 | arguments to `git merge` and/or `git pull`. |
566c5111 | 8 | |
bb73d73c | 9 | recursive:: |
4fa535a1 WC |
10 | This can only resolve two heads using a 3-way merge |
11 | algorithm. When there is more than one common | |
12 | ancestor that can be used for 3-way merge, it creates a | |
9688a882 | 13 | merged tree of the common ancestors and uses that as |
bb73d73c JL |
14 | the reference tree for the 3-way merge. This has been |
15 | reported to result in fewer merge conflicts without | |
13f72a1d | 16 | causing mismerges by tests done on actual merge commits |
bb73d73c JL |
17 | taken from Linux 2.6 kernel development history. |
18 | Additionally this can detect and handle merges involving | |
002a6dfc EN |
19 | renames. It does not make use of detected copies. This |
20 | is the default merge strategy when pulling or merging one | |
21 | branch. | |
566c5111 JH |
22 | + |
23 | The 'recursive' strategy can take the following options: | |
24 | ||
25 | ours;; | |
26 | This option forces conflicting hunks to be auto-resolved cleanly by | |
27 | favoring 'our' version. Changes from the other tree that do not | |
68d40f30 | 28 | conflict with our side are reflected in the merge result. |
a944af1d | 29 | For a binary file, the entire contents are taken from our side. |
566c5111 JH |
30 | + |
31 | This should not be confused with the 'ours' merge strategy, which does not | |
32 | even look at what the other tree contains at all. It discards everything | |
33 | the other tree did, declaring 'our' history contains all that happened in it. | |
34 | ||
35 | theirs;; | |
c25d98b2 | 36 | This is the opposite of 'ours'; note that, unlike 'ours', there is |
bd9958c3 | 37 | no 'theirs' merge strategy to confuse this merge option with. |
566c5111 | 38 | |
58a1ece4 JF |
39 | patience;; |
40 | With this option, 'merge-recursive' spends a little extra time | |
41 | to avoid mismerges that sometimes occur due to unimportant | |
42 | matching lines (e.g., braces from distinct functions). Use | |
43 | this when the branches to be merged have diverged wildly. | |
44 | See also linkgit:git-diff[1] `--patience`. | |
45 | ||
4db4f0fb | 46 | diff-algorithm=[patience|minimal|histogram|myers];; |
e80178ea EN |
47 | Use a different diff algorithm while merging, which can help |
48 | avoid mismerges that occur due to unimportant matching lines | |
49 | (such as braces from distinct functions). See also | |
50 | linkgit:git-diff[1] `--diff-algorithm`. Defaults to the | |
51 | `diff.algorithm` config setting. | |
4db4f0fb | 52 | |
4e5dd044 JF |
53 | ignore-space-change;; |
54 | ignore-all-space;; | |
55 | ignore-space-at-eol;; | |
e9282f02 | 56 | ignore-cr-at-eol;; |
4e5dd044 JF |
57 | Treats lines with the indicated type of whitespace change as |
58 | unchanged for the sake of a three-way merge. Whitespace | |
59 | changes mixed with other changes to a line are not ignored. | |
e9282f02 JH |
60 | See also linkgit:git-diff[1] `-b`, `-w`, |
61 | `--ignore-space-at-eol`, and `--ignore-cr-at-eol`. | |
4e5dd044 JF |
62 | + |
63 | * If 'their' version only introduces whitespace changes to a line, | |
64 | 'our' version is used; | |
65 | * If 'our' version introduces whitespace changes but 'their' | |
66 | version includes a substantial change, 'their' version is used; | |
67 | * Otherwise, the merge proceeds in the usual way. | |
68 | ||
7610fa57 JN |
69 | renormalize;; |
70 | This runs a virtual check-out and check-in of all three stages | |
71 | of a file when resolving a three-way merge. This option is | |
72 | meant to be used when merging branches with different clean | |
73 | filters or end-of-line normalization rules. See "Merging | |
74 | branches with differing checkin/checkout attributes" in | |
75 | linkgit:gitattributes[5] for details. | |
76 | ||
77 | no-renormalize;; | |
78 | Disables the `renormalize` option. This overrides the | |
79 | `merge.renormalize` configuration variable. | |
80 | ||
d2b11eca | 81 | no-renames;; |
85b46030 BP |
82 | Turn off rename detection. This overrides the `merge.renames` |
83 | configuration variable. | |
d2b11eca FGA |
84 | See also linkgit:git-diff[1] `--no-renames`. |
85 | ||
1b47ad16 | 86 | find-renames[=<n>];; |
83837ec0 | 87 | Turn on rename detection, optionally setting the similarity |
85b46030 BP |
88 | threshold. This is the default. This overrides the |
89 | 'merge.renames' configuration variable. | |
1b47ad16 FGA |
90 | See also linkgit:git-diff[1] `--find-renames`. |
91 | ||
10ae7526 | 92 | rename-threshold=<n>;; |
1b47ad16 | 93 | Deprecated synonym for `find-renames=<n>`. |
10ae7526 | 94 | |
62b4698e | 95 | subtree[=<path>];; |
566c5111 JH |
96 | This option is a more advanced form of 'subtree' strategy, where |
97 | the strategy makes a guess on how two trees must be shifted to | |
98 | match with each other when merging. Instead, the specified path | |
99 | is prefixed (or stripped from the beginning) to make the shape of | |
100 | two trees to match. | |
bb73d73c | 101 | |
510415ec EN |
102 | resolve:: |
103 | This can only resolve two heads (i.e. the current branch | |
104 | and another branch you pulled from) using a 3-way merge | |
105 | algorithm. It tries to carefully detect criss-cross | |
106 | merge ambiguities. It does not handle renames. | |
107 | ||
bb73d73c | 108 | octopus:: |
4fa535a1 WC |
109 | This resolves cases with more than two heads, but refuses to do |
110 | a complex merge that needs manual resolution. It is | |
bb73d73c JL |
111 | primarily meant to be used for bundling topic branch |
112 | heads together. This is the default merge strategy when | |
4fa535a1 | 113 | pulling or merging more than one branch. |
bb73d73c JL |
114 | |
115 | ours:: | |
d4cbaa12 TR |
116 | This resolves any number of heads, but the resulting tree of the |
117 | merge is always that of the current branch head, effectively | |
118 | ignoring all changes from all other branches. It is meant to | |
bb73d73c | 119 | be used to supersede old development history of side |
566c5111 JH |
120 | branches. Note that this is different from the -Xours option to |
121 | the 'recursive' merge strategy. | |
02b00e16 MV |
122 | |
123 | subtree:: | |
124 | This is a modified recursive strategy. When merging trees A and | |
125 | B, if B corresponds to a subtree of A, B is first adjusted to | |
126 | match the tree structure of A, instead of reading the trees at | |
127 | the same level. This adjustment is also done to the common | |
128 | ancestor tree. | |
c5665000 | 129 | |
130 | With the strategies that use 3-way merge (including the default, 'recursive'), | |
131 | if a change is made on both branches, but later reverted on one of the | |
132 | branches, that change will be present in the merged result; some people find | |
133 | this behavior confusing. It occurs because only the heads and the merge base | |
134 | are considered when performing a merge, not the individual commits. The merge | |
135 | algorithm therefore considers the reverted change as no change at all, and | |
136 | substitutes the changed version instead. |