Anonymous avatar Anonymous committed bb73d73

Refactor merge strategies into separate includable file.

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

Comments (0)

Files changed (3)

Documentation/git-merge.txt

 	least one <remote>.  Specifying more than one <remote>
 	obviously means you are trying an Octopus.
 
+include::merge-strategies.txt[]
+
 
 SEE ALSO
 --------

Documentation/git-pull.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

Documentation/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.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.