]>
Commit | Line | Data |
---|---|---|
bb73d73c JL |
1 | MERGE STRATEGIES |
2 | ---------------- | |
3 | ||
566c5111 JH |
4 | The merge mechanism ('git-merge' and 'git-pull' commands) allows the |
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>` | |
7 | arguments to 'git-merge' and/or 'git-pull'. | |
8 | ||
bb73d73c JL |
9 | resolve:: |
10 | This can only resolve two heads (i.e. the current branch | |
4fa535a1 | 11 | and another branch you pulled from) using a 3-way merge |
bb73d73c JL |
12 | algorithm. It tries to carefully detect criss-cross |
13 | merge ambiguities and is considered generally safe and | |
9688a882 | 14 | fast. |
bb73d73c JL |
15 | |
16 | recursive:: | |
4fa535a1 WC |
17 | This can only resolve two heads using a 3-way merge |
18 | algorithm. When there is more than one common | |
19 | ancestor that can be used for 3-way merge, it creates a | |
9688a882 | 20 | merged tree of the common ancestors and uses that as |
bb73d73c JL |
21 | the reference tree for the 3-way merge. This has been |
22 | reported to result in fewer merge conflicts without | |
23 | causing mis-merges by tests done on actual merge commits | |
24 | taken from Linux 2.6 kernel development history. | |
25 | Additionally this can detect and handle merges involving | |
9688a882 JH |
26 | renames. This is the default merge strategy when |
27 | pulling or merging one branch. | |
566c5111 JH |
28 | + |
29 | The 'recursive' strategy can take the following options: | |
30 | ||
31 | ours;; | |
32 | This option forces conflicting hunks to be auto-resolved cleanly by | |
33 | favoring 'our' version. Changes from the other tree that do not | |
34 | conflict with our side are reflected to the merge result. | |
35 | + | |
36 | This should not be confused with the 'ours' merge strategy, which does not | |
37 | even look at what the other tree contains at all. It discards everything | |
38 | the other tree did, declaring 'our' history contains all that happened in it. | |
39 | ||
40 | theirs;; | |
41 | This is opposite of 'ours'. | |
42 | ||
43 | subtree[=path];; | |
44 | This option is a more advanced form of 'subtree' strategy, where | |
45 | the strategy makes a guess on how two trees must be shifted to | |
46 | match with each other when merging. Instead, the specified path | |
47 | is prefixed (or stripped from the beginning) to make the shape of | |
48 | two trees to match. | |
bb73d73c JL |
49 | |
50 | octopus:: | |
4fa535a1 WC |
51 | This resolves cases with more than two heads, but refuses to do |
52 | a complex merge that needs manual resolution. It is | |
bb73d73c JL |
53 | primarily meant to be used for bundling topic branch |
54 | heads together. This is the default merge strategy when | |
4fa535a1 | 55 | pulling or merging more than one branch. |
bb73d73c JL |
56 | |
57 | ours:: | |
d4cbaa12 TR |
58 | This resolves any number of heads, but the resulting tree of the |
59 | merge is always that of the current branch head, effectively | |
60 | ignoring all changes from all other branches. It is meant to | |
bb73d73c | 61 | be used to supersede old development history of side |
566c5111 JH |
62 | branches. Note that this is different from the -Xours option to |
63 | the 'recursive' merge strategy. | |
02b00e16 MV |
64 | |
65 | subtree:: | |
66 | This is a modified recursive strategy. When merging trees A and | |
67 | B, if B corresponds to a subtree of A, B is first adjusted to | |
68 | match the tree structure of A, instead of reading the trees at | |
69 | the same level. This adjustment is also done to the common | |
70 | ancestor tree. |