mirror of
https://github.com/git/git
synced 2024-08-27 19:49:21 +00:00
Refactor merge strategies into separate includable file.
Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
parent
3402f1d6a3
commit
bb73d73c08
|
@ -34,6 +34,8 @@ include::merge-pull-opts.txt[]
|
|||
least one <remote>. Specifying more than one <remote>
|
||||
obviously means you are trying an Octopus.
|
||||
|
||||
include::merge-strategies.txt[]
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
|
|
@ -31,42 +31,8 @@ include::pull-fetch-param.txt[]
|
|||
|
||||
include::merge-pull-opts.txt[]
|
||||
|
||||
include::merge-strategies.txt[]
|
||||
|
||||
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
|
||||
fast. This is the default merge strategy when pulling
|
||||
one branch.
|
||||
|
||||
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
|
||||
merged tree of the common ancestores and uses that as
|
||||
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
|
||||
renames.
|
||||
|
||||
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
|
||||
pulling more than one branch.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
|
|
35
Documentation/merge-strategies.txt
Normal file
35
Documentation/merge-strategies.txt
Normal file
|
@ -0,0 +1,35 @@
|
|||
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
|
||||
fast. This is the default merge strategy when pulling
|
||||
one branch.
|
||||
|
||||
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
|
||||
merged tree of the common ancestores and uses that as
|
||||
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
|
||||
renames.
|
||||
|
||||
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
|
||||
pulling more than one branch.
|
||||
|
||||
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.
|
Loading…
Reference in a new issue