summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 3402f1d)
raw | patch | inline | side by side (parent: 3402f1d)
author | Jon Loeliger <jdl@freescale.com> | |
Sun, 6 Nov 2005 16:26:07 +0000 (10:26 -0600) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Sun, 6 Nov 2005 18:31:48 +0000 (10:31 -0800) |
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-merge.txt | patch | blob | history | |
Documentation/git-pull.txt | patch | blob | history | |
Documentation/merge-strategies.txt | [new file with mode: 0644] | patch | blob |
index 3e058db996cbb1200fc304b3a090cbd4e13fce80..b3ef19bae44268a3a2159f9ccfbce51314312ab7 100644 (file)
least one <remote>. Specifying more than one <remote>
obviously means you are trying an Octopus.
+include::merge-strategies.txt[]
+
SEE ALSO
--------
index ec10a2f409a6cd3d7340cfc934c53ccd5a00f5f0..7ebb08da0c7c9065b1d26398601f69584fc867ef 100644 (file)
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
--- /dev/null
@@ -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.