From: Jon Loeliger <jdl@freescale.com>
To: git@vger.kernel.org
Subject: [PATCH] Refactor merge strategies into separate includable file.
Date: Sun, 06 Nov 2005 10:26:07 -0600 [thread overview]
Message-ID: <E1EYnLL-00028e-CY@jdl.com> (raw)
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/git-merge.txt | 2 ++
Documentation/git-pull.txt | 36 +-----------------------------------
Documentation/merge-strategies.txt | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 38 insertions(+), 35 deletions(-)
create mode 100644 Documentation/merge-strategies.txt
applies-to: 2a5577073c7747c11ad79f414603e68c5d95cf6b
ceda5bc3b5cb502edb3c0596aeede1a0ab9d4295
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 3e058db..b3ef19b 100644
--- 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
--- 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
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.
---
0.99.9.GIT
reply other threads:[~2005-11-06 16:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1EYnLL-00028e-CY@jdl.com \
--to=jdl@freescale.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.