mirror of
https://github.com/git/git
synced 2024-08-27 11:39:22 +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>
|
least one <remote>. Specifying more than one <remote>
|
||||||
obviously means you are trying an Octopus.
|
obviously means you are trying an Octopus.
|
||||||
|
|
||||||
|
include::merge-strategies.txt[]
|
||||||
|
|
||||||
|
|
||||||
SEE ALSO
|
SEE ALSO
|
||||||
--------
|
--------
|
||||||
|
|
|
@ -31,42 +31,8 @@ include::pull-fetch-param.txt[]
|
||||||
|
|
||||||
include::merge-pull-opts.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
|
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