2005-11-06 17:26:07 +01:00
|
|
|
MERGE STRATEGIES
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
resolve::
|
|
|
|
|
This can only resolve two heads (i.e. the current branch
|
|
|
|
|
and another branch you pulled from) using 3-way merge
|
|
|
|
|
algorithm. It tries to carefully detect criss-cross
|
|
|
|
|
merge ambiguities and is considered generally safe and
|
2005-12-08 23:04:33 +01:00
|
|
|
fast.
|
2005-11-06 17:26:07 +01:00
|
|
|
|
|
|
|
|
recursive::
|
|
|
|
|
This can only resolve two heads using 3-way merge
|
|
|
|
|
algorithm. When there are more than one common
|
|
|
|
|
ancestors that can be used for 3-way merge, it creates a
|
2005-12-08 23:04:33 +01:00
|
|
|
merged tree of the common ancestors and uses that as
|
2005-11-06 17:26:07 +01:00
|
|
|
the reference tree for the 3-way merge. This has been
|
|
|
|
|
reported to result in fewer merge conflicts without
|
|
|
|
|
causing mis-merges by tests done on actual merge commits
|
|
|
|
|
taken from Linux 2.6 kernel development history.
|
|
|
|
|
Additionally this can detect and handle merges involving
|
2005-12-08 23:04:33 +01:00
|
|
|
renames. This is the default merge strategy when
|
|
|
|
|
pulling or merging one branch.
|
2005-11-06 17:26:07 +01:00
|
|
|
|
|
|
|
|
octopus::
|
|
|
|
|
This resolves more than two-head case, but refuses to do
|
|
|
|
|
complex merge that needs manual resolution. It is
|
|
|
|
|
primarily meant to be used for bundling topic branch
|
|
|
|
|
heads together. This is the default merge strategy when
|
2005-12-08 23:04:33 +01:00
|
|
|
pulling or merging more than one branches.
|
2005-11-06 17:26:07 +01:00
|
|
|
|
|
|
|
|
ours::
|
|
|
|
|
This resolves any number of heads, but the result of the
|
|
|
|
|
merge is always the current branch head. It is meant to
|
|
|
|
|
be used to supersede old development history of side
|
|
|
|
|
branches.
|
