-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
--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.
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.
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
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
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;;
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
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
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
projects / thirdparty / git.git / commitdiff
