diff options
author | Junio C Hamano <gitster@pobox.com> | 2021-08-31 02:06:01 +0300 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-08-31 02:06:01 +0300 |
commit | aca13c2355e7188432cb32aedf0bb0c477ec011a (patch) | |
tree | 424f1e238007c0f5a1b2f97d1fc8b0bb71f61d30 /Documentation | |
parent | 7d0daf3f12f87799a3b3f524933ef6c15d1f28c3 (diff) | |
parent | 81483fe613de70e17913167876676528cb37cbcd (diff) |
Merge branch 'en/merge-strategy-docs'
Documentation updates.
* en/merge-strategy-docs:
Update error message and code comment
merge-strategies.txt: add coverage of the `ort` merge strategy
git-rebase.txt: correct out-of-date and misleading text about renames
merge-strategies.txt: fix simple capitalization error
merge-strategies.txt: avoid giving special preference to patience algorithm
merge-strategies.txt: do not imply using copy detection is desired
merge-strategies.txt: update wording for the resolve strategy
Documentation: edit awkward references to `git merge-recursive`
directory-rename-detection.txt: small updates due to merge-ort optimizations
git-rebase.txt: correct antiquated claims about --rebase-merges
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/git-rebase.txt | 27 | ||||
-rw-r--r-- | Documentation/merge-options.txt | 4 | ||||
-rw-r--r-- | Documentation/merge-strategies.txt | 48 | ||||
-rw-r--r-- | Documentation/technical/directory-rename-detection.txt | 14 |
4 files changed, 53 insertions, 40 deletions
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 55af6fd24e..73d49ec8d9 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -340,9 +340,7 @@ See also INCOMPATIBLE OPTIONS below. -m:: --merge:: - Use merging strategies to rebase. When the recursive (default) merge - strategy is used, this allows rebase to be aware of renames on the - upstream side. This is the default. + Using merging strategies to rebase (default). + Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge @@ -354,9 +352,8 @@ See also INCOMPATIBLE OPTIONS below. -s <strategy>:: --strategy=<strategy>:: - Use the given merge strategy. - If there is no `-s` option 'git merge-recursive' is used - instead. This implies --merge. + Use the given merge strategy, instead of the default + `recursive`. This implies `--merge`. + Because 'git rebase' replays each commit from the working branch on top of the <upstream> branch using the given strategy, using @@ -530,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 +`recursive` 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. @@ -1219,12 +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. -At this time, the `merge` command will *always* use the `recursive` -merge strategy for regular merges, and `octopus` for octopus merges, -with no way to choose a different one. To work around -this, an `exec` command can be used to call `git merge` explicitly, -using the fact that the labels are worktree-local refs (the ref -`refs/rewritten/onto` would correspond to the label `onto`, for example). +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. 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 diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 86b0eeb851..86f277a994 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -144,8 +144,8 @@ endif::git-pull[] 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 ('git merge-recursive' when merging a single - head, 'git merge-octopus' otherwise). + is used instead (`recursive` when merging a single head, + `octopus` otherwise). -X <option>:: --strategy-option=<option>:: diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 2912de706b..210f0f850b 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -6,13 +6,6 @@ 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`. -resolve:: - This can only resolve two heads (i.e. the current branch - and another branch you pulled from) using a 3-way merge - algorithm. It tries to carefully detect criss-cross - merge ambiguities and is considered generally safe and - fast. - recursive:: This can only resolve two heads using a 3-way merge algorithm. When there is more than one common @@ -23,9 +16,9 @@ recursive:: 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, but currently cannot make use of detected - copies. This is the default merge strategy when pulling - or merging one branch. + renames. It does not make use of detected copies. This + is the default merge strategy when pulling or merging one + branch. + The 'recursive' strategy can take the following options: @@ -44,17 +37,14 @@ theirs;; no 'theirs' merge strategy to confuse this merge option with. patience;; - With this option, 'merge-recursive' spends a little extra time - to avoid mismerges that sometimes occur due to unimportant - matching lines (e.g., braces from distinct functions). Use - this when the branches to be merged have diverged wildly. - See also linkgit:git-diff[1] `--patience`. + Deprecated synonym for `diff-algorithm=patience`. diff-algorithm=[patience|minimal|histogram|myers];; - Tells 'merge-recursive' to use a different diff algorithm, 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`. + 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;; @@ -105,6 +95,26 @@ 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. ++ +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`. + +resolve:: + This can only resolve two heads (i.e. the current branch + and another branch you pulled from) using a 3-way merge + algorithm. It tries to carefully detect criss-cross + merge ambiguities. It does not handle renames. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is diff --git a/Documentation/technical/directory-rename-detection.txt b/Documentation/technical/directory-rename-detection.txt index 49b83ef3cc..029ee2cedc 100644 --- a/Documentation/technical/directory-rename-detection.txt +++ b/Documentation/technical/directory-rename-detection.txt @@ -2,9 +2,9 @@ Directory rename detection ========================== Rename detection logic in diffcore-rename that checks for renames of -individual files is aggregated and analyzed in merge-recursive for cases -where combinations of renames indicate that a full directory has been -renamed. +individual files is also aggregated there and then analyzed in either +merge-ort or merge-recursive for cases where combinations of renames +indicate that a full directory has been renamed. Scope of abilities ------------------ @@ -88,9 +88,11 @@ directory rename detection support in: Folks have requested in the past that `git diff` detect directory renames and somehow simplify its output. It is not clear whether this would be desirable or how the output should be simplified, so this was - simply not implemented. Further, to implement this, directory rename - detection logic would need to move from merge-recursive to - diffcore-rename. + simply not implemented. Also, while diffcore-rename has most of the + logic for detecting directory renames, some of the logic is still found + within merge-ort and merge-recursive. Fully supporting directory + rename detection in diffs would require copying or moving the remaining + bits of logic to the diff machinery. * am |