]>
Commit | Line | Data |
---|---|---|
bb73d73c JL |
1 | MERGE STRATEGIES |
2 | ---------------- | |
3 | ||
4 | resolve:: | |
5 | This can only resolve two heads (i.e. the current branch | |
6 | and another branch you pulled from) using 3-way merge | |
7 | algorithm. It tries to carefully detect criss-cross | |
8 | merge ambiguities and is considered generally safe and | |
9 | fast. This is the default merge strategy when pulling | |
10 | one branch. | |
11 | ||
12 | recursive:: | |
13 | This can only resolve two heads using 3-way merge | |
14 | algorithm. When there are more than one common | |
15 | ancestors that can be used for 3-way merge, it creates a | |
16 | merged tree of the common ancestores and uses that as | |
17 | the reference tree for the 3-way merge. This has been | |
18 | reported to result in fewer merge conflicts without | |
19 | causing mis-merges by tests done on actual merge commits | |
20 | taken from Linux 2.6 kernel development history. | |
21 | Additionally this can detect and handle merges involving | |
22 | renames. | |
23 | ||
24 | octopus:: | |
25 | This resolves more than two-head case, but refuses to do | |
26 | complex merge that needs manual resolution. It is | |
27 | primarily meant to be used for bundling topic branch | |
28 | heads together. This is the default merge strategy when | |
29 | pulling more than one branch. | |
30 | ||
31 | ours:: | |
32 | This resolves any number of heads, but the result of the | |
33 | merge is always the current branch head. It is meant to | |
34 | be used to supersede old development history of side | |
35 | branches. |