Update docs for change of default merge backend

Make it clear that `ort` is the default merge strategy now rather than
`recursive`, including moving `ort` to the front of the list of merge
strategies.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull/1083/head
Elijah Newren 1 year ago committed by Junio C Hamano
parent 6a5fb96672
commit f5a3c5e637
  1. 28
      Documentation/git-rebase.txt
  2. 2
      Documentation/gitfaq.txt
  3. 2
      Documentation/merge-options.txt
  4. 93
      Documentation/merge-strategies.txt
  5. 2
      Documentation/user-manual.txt

@ -352,8 +352,8 @@ See also INCOMPATIBLE OPTIONS below.
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy, instead of the default
`recursive`. This implies `--merge`.
Use the given merge strategy, instead of the default `ort`.
This implies `--merge`.
+
Because 'git rebase' replays each commit from the working branch
on top of the <upstream> branch using the given strategy, using
@ -366,7 +366,7 @@ See also INCOMPATIBLE OPTIONS below.
--strategy-option=<strategy-option>::
Pass the <strategy-option> through to the merge strategy.
This implies `--merge` and, if no strategy has been
specified, `-s recursive`. Note the reversal of 'ours' and
specified, `-s ort`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
+
See also INCOMPATIBLE OPTIONS below.
@ -527,7 +527,7 @@ The `--rebase-merges` mode is similar in spirit to the deprecated
where commits can be reordered, inserted and dropped at will.
+
It is currently only possible to recreate the merge commits using the
`recursive` merge strategy; different merge strategies can be used only via
`ort` merge strategy; different merge strategies can be used only via
explicit `exec git merge -s <strategy> [...]` commands.
+
See also REBASING MERGES and INCOMPATIBLE OPTIONS below.
@ -1216,16 +1216,16 @@ successful merge so that the user can edit the message.
If a `merge` command fails for any reason other than merge conflicts (i.e.
when the merge operation did not even start), it is rescheduled immediately.
By default, the `merge` command will use the `recursive` merge
strategy for regular merges, and `octopus` for octopus merges. One
can specify a default strategy for all merges using the `--strategy`
argument when invoking rebase, or can override specific merges in the
interactive list of commands by using an `exec` command to call `git
merge` explicitly with a `--strategy` argument. Note that when
calling `git merge` explicitly like this, you can make use of the fact
that the labels are worktree-local refs (the ref `refs/rewritten/onto`
would correspond to the label `onto`, for example) in order to refer
to the branches you want to merge.
By default, the `merge` command will use the `ort` merge strategy for
regular merges, and `octopus` for octopus merges. One can specify a
default strategy for all merges using the `--strategy` argument when
invoking rebase, or can override specific merges in the interactive
list of commands by using an `exec` command to call `git merge`
explicitly with a `--strategy` argument. Note that when calling `git
merge` explicitly like this, you can make use of the fact that the
labels are worktree-local refs (the ref `refs/rewritten/onto` would
correspond to the label `onto`, for example) in order to refer to the
branches you want to merge.
Note: the first command (`label onto`) labels the revision onto which
the commits are rebased; The name `onto` is just a convention, as a nod

@ -275,7 +275,7 @@ best to always use a regular merge commit.
[[merge-two-revert-one]]
If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
By default, when Git does a merge, it uses a strategy called the recursive
By default, when Git does a merge, it uses a strategy called the `ort`
strategy, which does a fancy three-way merge. In such a case, when Git
performs the merge, it considers exactly three points: the two heads and a
third point, called the _merge base_, which is usually the common ancestor of

@ -112,7 +112,7 @@ With --squash, --commit is not allowed, and will fail.
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no `-s` option, a built-in list of strategies
is used instead (`recursive` when merging a single head,
is used instead (`ort` when merging a single head,
`octopus` otherwise).
-X <option>::

@ -6,21 +6,23 @@ backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-X<option>`
arguments to `git merge` and/or `git pull`.
recursive::
This can only resolve two heads using a 3-way merge
algorithm. When there is more than one common
ancestor that can be used for 3-way merge, it creates a
merged tree of the common ancestors and uses that as
the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without
causing mismerges by tests done on actual merge commits
taken from Linux 2.6 kernel development history.
Additionally this can detect and handle merges involving
renames. It does not make use of detected copies. This
is the default merge strategy when pulling or merging one
branch.
ort::
This is the default merge strategy when pulling or merging one
branch. This strategy can only resolve two heads using a
3-way merge algorithm. When there is more than one common
ancestor that can be used for 3-way merge, it creates a merged
tree of the common ancestors and uses that as the reference
tree for the 3-way merge. This has been reported to result in
fewer merge conflicts without causing mismerges by tests done
on actual merge commits taken from Linux 2.6 kernel
development history. Additionally this strategy can detect
and handle merges involving renames. It does not make use of
detected copies. The name for this algorithm is an acronym
("Ostensibly Recursive's Twin") and came from the fact that it
was written as a replacement for the previous default
algorithm, `recursive`.
+
The 'recursive' strategy can take the following options:
The 'ort' strategy can take the following options:
ours;;
This option forces conflicting hunks to be auto-resolved cleanly by
@ -36,16 +38,6 @@ theirs;;
This is the opposite of 'ours'; note that, unlike 'ours', there is
no 'theirs' merge strategy to confuse this merge option with.
patience;;
Deprecated synonym for `diff-algorithm=patience`.
diff-algorithm=[patience|minimal|histogram|myers];;
Use a different diff algorithm while merging, which can help
avoid mismerges that occur due to unimportant matching lines
(such as braces from distinct functions). See also
linkgit:git-diff[1] `--diff-algorithm`. Defaults to the
`diff.algorithm` config setting.
ignore-space-change;;
ignore-all-space;;
ignore-space-at-eol;;
@ -74,11 +66,6 @@ no-renormalize;;
Disables the `renormalize` option. This overrides the
`merge.renormalize` configuration variable.
no-renames;;
Turn off rename detection. This overrides the `merge.renames`
configuration variable.
See also linkgit:git-diff[1] `--no-renames`.
find-renames[=<n>];;
Turn on rename detection, optionally setting the similarity
threshold. This is the default. This overrides the
@ -95,19 +82,39 @@ subtree[=<path>];;
is prefixed (or stripped from the beginning) to make the shape of
two trees to match.
ort::
This is meant as a drop-in replacement for the `recursive`
algorithm (as reflected in its acronym -- "Ostensibly
Recursive's Twin"), and will likely replace it in the future.
It fixes corner cases that the `recursive` strategy handles
suboptimally, and is significantly faster in large
repositories -- especially when many renames are involved.
recursive::
This can only resolve two heads using a 3-way merge
algorithm. When there is more than one common
ancestor that can be used for 3-way merge, it creates a
merged tree of the common ancestors and uses that as
the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without
causing mismerges by tests done on actual merge commits
taken from Linux 2.6 kernel development history.
Additionally this can detect and handle merges involving
renames. It does not make use of detected copies. This was
the default strategy for resolving two heads from Git v0.99.9k
until v2.33.0.
+
The `ort` strategy takes all the same options as `recursive`.
However, it ignores three of those options: `no-renames`,
`patience` and `diff-algorithm`. It always runs with rename
detection (it handles it much faster than `recursive` does), and
it specifically uses `diff-algorithm=histogram`.
The 'recursive' strategy takes the same options as 'ort'. However,
there are three additional options that 'ort' ignores (not documented
above) that are potentially useful with the 'recursive' strategy:
patience;;
Deprecated synonym for `diff-algorithm=patience`.
diff-algorithm=[patience|minimal|histogram|myers];;
Use a different diff algorithm while merging, which can help
avoid mismerges that occur due to unimportant matching lines
(such as braces from distinct functions). See also
linkgit:git-diff[1] `--diff-algorithm`. Note that `ort`
specifically uses `diff-algorithm=histogram`, while `recursive`
defaults to the `diff.algorithm` config setting.
no-renames;;
Turn off rename detection. This overrides the `merge.renames`
configuration variable.
See also linkgit:git-diff[1] `--no-renames`.
resolve::
This can only resolve two heads (i.e. the current branch
@ -131,13 +138,13 @@ ours::
the 'recursive' merge strategy.
subtree::
This is a modified recursive strategy. When merging trees A and
This is a modified `ort` strategy. When merging trees A and
B, if B corresponds to a subtree of A, B is first adjusted to
match the tree structure of A, instead of reading the trees at
the same level. This adjustment is also done to the common
ancestor tree.
With the strategies that use 3-way merge (including the default, 'recursive'),
With the strategies that use 3-way merge (including the default, 'ort'),
if a change is made on both branches, but later reverted on one of the
branches, that change will be present in the merged result; some people find
this behavior confusing. It occurs because only the heads and the merge base

@ -3190,7 +3190,7 @@ that *updated* thing--the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob
object.
Similarly, when the "recursive" merge strategy runs, and finds that
Similarly, when the "ort" merge strategy runs, and finds that
there are criss-cross merges and thus more than one merge base (which is
fairly unusual, but it does happen), it will generate one temporary
midway tree (or possibly even more, if you had lots of criss-crossing

Loading…
Cancel
Save