| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 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. |
| 10 | |
| 11 | recursive:: |
| 12 | This can only resolve two heads using 3-way merge |
| 13 | algorithm. When there are more than one common |
| 14 | ancestors that can be used for 3-way merge, it creates a |
| 15 | merged tree of the common ancestors and uses that as |
| 16 | the reference tree for the 3-way merge. This has been |
| 17 | reported to result in fewer merge conflicts without |
| 18 | causing mis-merges by tests done on actual merge commits |
| 19 | taken from Linux 2.6 kernel development history. |
| 20 | Additionally this can detect and handle merges involving |
| 21 | renames. This is the default merge strategy when |
| 22 | pulling or merging one branch. |
| 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 or merging more than one branches. |
| 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. |
