Refactor merge strategies into separate includable file.

Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 3e058db..b3ef19b 100644 (file)
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -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
 --------

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index ec10a2f..7ebb08d 100644 (file)
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -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

diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
new file mode 100644 (file)
index 0000000..3ec56d2
--- /dev/null
+++ b/Documentation/merge-strategies.txt
@@ -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.