From: Jon Loeliger Date: Sun, 6 Nov 2005 16:26:07 +0000 (-0600) Subject: Refactor merge strategies into separate includable file. X-Git-Tag: v0.99.9e^2~7 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=bb73d73c0885fce357e0d70aa51c2215a8e38a4e;p=git.git Refactor merge strategies into separate includable file. Signed-off-by: Jon Loeliger Signed-off-by: Junio C Hamano --- diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 3e058db99..b3ef19bae 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -34,6 +34,8 @@ include::merge-pull-opts.txt[] least one . Specifying more than one 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 ec10a2f40..7ebb08da0 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 000000000..3ec56d22e --- /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.