* [PATCH 0/2] Switch default merge backend from recursive to ort @ 2021-08-04 5:38 Elijah Newren via GitGitGadget 2021-08-04 5:38 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Elijah Newren via GitGitGadget @ 2021-08-04 5:38 UTC (permalink / raw) To: git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren This is a reroll of my RFC series[1] to switch the default merge backend from recursive to ort. The consensus seems to be that we should do this immediately after the 2.33 release. Note that folks who want to get the old merge backend after this series can simply set pull.twohead=recursive. (And, similarly, before this series, those who want to try out ort in Git 2.32 or Git 2.33 can set pull.twohead=ort.) Changes since the RFC version of this series: * Now depends on the reroll of en/merge-strategy-docs I just submitted[2]. * Made tweaks to code and documentation suggested by Stolee, Dscho, and Ævar [1] https://lore.kernel.org/git/pull.1055.git.git.1627776461.gitgitgadget@gmail.com/ [2] https://lore.kernel.org/git/pull.1059.git.git.1628004920.gitgitgadget@gmail.com/ Elijah Newren (2): Change default merge backend from recursive to ort Update docs for change of default merge backend Documentation/git-rebase.txt | 28 ++++----- Documentation/gitfaq.txt | 2 +- Documentation/merge-options.txt | 2 +- Documentation/merge-strategies.txt | 93 ++++++++++++++++-------------- Documentation/user-manual.txt | 2 +- builtin/merge.c | 10 +++- builtin/rebase.c | 2 +- sequencer.c | 4 +- 8 files changed, 78 insertions(+), 65 deletions(-) base-commit: 4a78ac53424525d7099867d5a4377b8afb9bf18f Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1011%2Fnewren%2Fort-default-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1011/newren/ort-default-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/1011 -- gitgitgadget ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/2] Change default merge backend from recursive to ort 2021-08-04 5:38 [PATCH 0/2] Switch default merge backend from recursive to ort Elijah Newren via GitGitGadget @ 2021-08-04 5:38 ` Elijah Newren via GitGitGadget 2021-08-09 17:38 ` Phillip Wood 2021-08-04 5:38 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget 2021-08-04 14:27 ` [PATCH 0/2] Switch default merge backend from recursive to ort Derrick Stolee 2 siblings, 1 reply; 10+ messages in thread From: Elijah Newren via GitGitGadget @ 2021-08-04 5:38 UTC (permalink / raw) To: git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren, Elijah Newren From: Elijah Newren <newren@gmail.com> There are a few reasons to switch the default: * Correctness * Extensibility * Performance I'll provide some summaries about each. === Correctness === The original impetus for a new merge backend was to fix issues that were difficult to fix within recursive's design. The success with this goal is perhaps most easily demonstrated by running the following: $ git grep -2 KNOWN_FAILURE t/ | grep -A 4 GIT_TEST_MERGE_ALGORITHM $ git grep test_expect_merge_algorithm.failure.success t/ $ git grep test_expect_merge_algorithm.success.failure t/ In order, these greps show: * Seven sets of submodule tests (10 total tests) that fail with recursive but succeed with ort * 22 other tests that fail with recursive, but succeed with ort * 0 tests that pass with recursive, but fail with ort === Extensibility === Being able to perform merges without touching the working tree or index makes it possible to create new features that were difficult with the old backend: * Merging, cherry-picking, rebasing, reverting in bare repositories... or just on branches that aren't checked out. * `git diff AUTO_MERGE` -- ability to see what changes the user has made to resolve conflicts so far (see commit 5291828df8 ("merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict", 2021-03-20) * A --remerge-diff option for log/show, used to show diffs for merges that display the difference between what an automatic merge would have created and what was recorded in the merge. (This option will often result in an empty diff because many merges are clean, but for the non-clean ones it will show how conflicts were fixed including the removal of conflict markers, and also show additional changes made outside of conflict regions to e.g. fix semantic conflicts.) * A --remerge-diff-only option for log/show, similar to --remerge-diff but also showing how cherry-picks or reverts differed from what an automatic cherry-pick or revert would provide. The last three have been implemented already (though only one has been submitted upstream so far; the others were waiting for performance work to complete), and I still plan to implement the first one. === Performance === I'll quote from the summary of my final optimization for merge-ort (while fixing the testcase name from 'no-renames' to 'few-renames'): Timings Infinite merge- merge- Parallelism recursive recursive of rename merge-ort v2.30.0 current detection current ---------- --------- ----------- --------- few-renames: 18.912 s 18.030 s 11.699 s 198.3 ms mega-renames: 5964.031 s 361.281 s 203.886 s 661.8 ms just-one-mega: 149.583 s 11.009 s 7.553 s 264.6 ms Speedup factors Infinite merge- merge- Parallelism recursive recursive of rename v2.30.0 current detection merge-ort ---------- --------- ----------- --------- few-renames: 1 1.05 1.6 95 mega-renames: 1 16.5 29 9012 just-one-mega: 1 13.6 20 565 And, for partial clone users: Factor reduction in number of objects needed Infinite merge- merge- Parallelism recursive recursive of rename v2.30.0 current detection merge-ort ---------- --------- ----------- --------- mega-renames: 1 1 1 181.3 Signed-off-by: Elijah Newren <newren@gmail.com> --- builtin/merge.c | 10 ++++++++-- builtin/rebase.c | 2 +- sequencer.c | 4 ++-- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/builtin/merge.c b/builtin/merge.c index d7b14bf4a7f..fbe21d413c1 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -88,9 +88,9 @@ static int autostash; static int no_verify; static struct strategy all_strategy[] = { - { "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL }, + { "recursive", NO_TRIVIAL }, { "octopus", DEFAULT_OCTOPUS }, - { "ort", NO_TRIVIAL }, + { "ort", DEFAULT_TWOHEAD | NO_TRIVIAL }, { "resolve", 0 }, { "ours", NO_FAST_FORWARD | NO_TRIVIAL }, { "subtree", NO_FAST_FORWARD | NO_TRIVIAL }, @@ -1484,6 +1484,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix) fast_forward = FF_NO; } + if (!use_strategies && !pull_twohead && + remoteheads && !remoteheads->next) { + char *default_strategy = getenv("GIT_TEST_MERGE_ALGORITHM"); + if (default_strategy) + append_strategy(get_strategy(default_strategy)); + } if (!use_strategies) { if (!remoteheads) ; /* already up-to-date */ diff --git a/builtin/rebase.c b/builtin/rebase.c index 12f093121d9..587a2f1d299 100644 --- a/builtin/rebase.c +++ b/builtin/rebase.c @@ -1713,7 +1713,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix) int i; if (!options.strategy) - options.strategy = "recursive"; + options.strategy = "ort"; strbuf_reset(&buf); for (i = 0; i < strategy_options.nr; i++) diff --git a/sequencer.c b/sequencer.c index a4e5c43fcf2..d08ddae52fa 100644 --- a/sequencer.c +++ b/sequencer.c @@ -636,7 +636,7 @@ static int do_recursive_merge(struct repository *r, for (i = 0; i < opts->xopts_nr; i++) parse_merge_opt(&o, opts->xopts[i]); - if (opts->strategy && !strcmp(opts->strategy, "ort")) { + if (!opts->strategy || !strcmp(opts->strategy, "ort")) { memset(&result, 0, sizeof(result)); merge_incore_nonrecursive(&o, base_tree, head_tree, next_tree, &result); @@ -3988,7 +3988,7 @@ static int do_merge(struct repository *r, o.branch2 = ref_name.buf; o.buffer_output = 2; - if (opts->strategy && !strcmp(opts->strategy, "ort")) { + if (!opts->strategy || !strcmp(opts->strategy, "ort")) { /* * TODO: Should use merge_incore_recursive() and * merge_switch_to_result(), skipping the call to -- gitgitgadget ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] Change default merge backend from recursive to ort 2021-08-04 5:38 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget @ 2021-08-09 17:38 ` Phillip Wood 2021-08-09 21:01 ` Elijah Newren 0 siblings, 1 reply; 10+ messages in thread From: Phillip Wood @ 2021-08-09 17:38 UTC (permalink / raw) To: Elijah Newren via GitGitGadget, git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren Hi Elijah On 04/08/2021 06:38, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@gmail.com> > > There are a few reasons to switch the default: > * Correctness > * Extensibility > * Performance > > I'll provide some summaries about each. > > === Correctness === > > The original impetus for a new merge backend was to fix issues that were > difficult to fix within recursive's design. The success with this goal > is perhaps most easily demonstrated by running the following: > > $ git grep -2 KNOWN_FAILURE t/ | grep -A 4 GIT_TEST_MERGE_ALGORITHM > $ git grep test_expect_merge_algorithm.failure.success t/ > $ git grep test_expect_merge_algorithm.success.failure t/ > > In order, these greps show: > > * Seven sets of submodule tests (10 total tests) that fail with > recursive but succeed with ort > * 22 other tests that fail with recursive, but succeed with ort > * 0 tests that pass with recursive, but fail with ort I've not followed your patches too closely but I did notice you seem to have put a lot of effort into improving the test coverage which is fantastic. > === Extensibility === > > Being able to perform merges without touching the working tree or index > makes it possible to create new features that were difficult with the > old backend: > > * Merging, cherry-picking, rebasing, reverting in bare repositories... > or just on branches that aren't checked out. Rebasing without updating the worktree for each commit is exciting. I agree with others that this should be merged into next sooner rather than later. I also agree with Peff's point about moving it into master to get more people using it rather than sitting in next for too long. I think the sequencer changes below are easier to follow in this version. One thing I did wonder is whether there needs to be any change to the CI scripts to ensure we keep testing both merge implementations. Best wishes and congratulations on an impressive achievement Phillip > * `git diff AUTO_MERGE` -- ability to see what changes the user has > made to resolve conflicts so far (see commit 5291828df8 ("merge-ort: > write $GIT_DIR/AUTO_MERGE whenever we hit a conflict", 2021-03-20) > > * A --remerge-diff option for log/show, used to show diffs for merges > that display the difference between what an automatic merge would > have created and what was recorded in the merge. (This option will > often result in an empty diff because many merges are clean, but for > the non-clean ones it will show how conflicts were fixed including > the removal of conflict markers, and also show additional changes > made outside of conflict regions to e.g. fix semantic conflicts.) > > * A --remerge-diff-only option for log/show, similar to --remerge-diff > but also showing how cherry-picks or reverts differed from what an > automatic cherry-pick or revert would provide. > > The last three have been implemented already (though only one has been > submitted upstream so far; the others were waiting for performance work > to complete), and I still plan to implement the first one. > > === Performance === > > I'll quote from the summary of my final optimization for merge-ort > (while fixing the testcase name from 'no-renames' to 'few-renames'): > > Timings > > Infinite > merge- merge- Parallelism > recursive recursive of rename merge-ort > v2.30.0 current detection current > ---------- --------- ----------- --------- > few-renames: 18.912 s 18.030 s 11.699 s 198.3 ms > mega-renames: 5964.031 s 361.281 s 203.886 s 661.8 ms > just-one-mega: 149.583 s 11.009 s 7.553 s 264.6 ms > > Speedup factors > > Infinite > merge- merge- Parallelism > recursive recursive of rename > v2.30.0 current detection merge-ort > ---------- --------- ----------- --------- > few-renames: 1 1.05 1.6 95 > mega-renames: 1 16.5 29 9012 > just-one-mega: 1 13.6 20 565 > > And, for partial clone users: > > Factor reduction in number of objects needed > > Infinite > merge- merge- Parallelism > recursive recursive of rename > v2.30.0 current detection merge-ort > ---------- --------- ----------- --------- > mega-renames: 1 1 1 181.3 > > Signed-off-by: Elijah Newren <newren@gmail.com> > --- > builtin/merge.c | 10 ++++++++-- > builtin/rebase.c | 2 +- > sequencer.c | 4 ++-- > 3 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/builtin/merge.c b/builtin/merge.c > index d7b14bf4a7f..fbe21d413c1 100644 > --- a/builtin/merge.c > +++ b/builtin/merge.c > @@ -88,9 +88,9 @@ static int autostash; > static int no_verify; > > static struct strategy all_strategy[] = { > - { "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL }, > + { "recursive", NO_TRIVIAL }, > { "octopus", DEFAULT_OCTOPUS }, > - { "ort", NO_TRIVIAL }, > + { "ort", DEFAULT_TWOHEAD | NO_TRIVIAL }, > { "resolve", 0 }, > { "ours", NO_FAST_FORWARD | NO_TRIVIAL }, > { "subtree", NO_FAST_FORWARD | NO_TRIVIAL }, > @@ -1484,6 +1484,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix) > fast_forward = FF_NO; > } > > + if (!use_strategies && !pull_twohead && > + remoteheads && !remoteheads->next) { > + char *default_strategy = getenv("GIT_TEST_MERGE_ALGORITHM"); > + if (default_strategy) > + append_strategy(get_strategy(default_strategy)); > + } > if (!use_strategies) { > if (!remoteheads) > ; /* already up-to-date */ > diff --git a/builtin/rebase.c b/builtin/rebase.c > index 12f093121d9..587a2f1d299 100644 > --- a/builtin/rebase.c > +++ b/builtin/rebase.c > @@ -1713,7 +1713,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix) > int i; > > if (!options.strategy) > - options.strategy = "recursive"; > + options.strategy = "ort"; > > strbuf_reset(&buf); > for (i = 0; i < strategy_options.nr; i++) > diff --git a/sequencer.c b/sequencer.c > index a4e5c43fcf2..d08ddae52fa 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -636,7 +636,7 @@ static int do_recursive_merge(struct repository *r, > for (i = 0; i < opts->xopts_nr; i++) > parse_merge_opt(&o, opts->xopts[i]); > > - if (opts->strategy && !strcmp(opts->strategy, "ort")) { > + if (!opts->strategy || !strcmp(opts->strategy, "ort")) { > memset(&result, 0, sizeof(result)); > merge_incore_nonrecursive(&o, base_tree, head_tree, next_tree, > &result); > @@ -3988,7 +3988,7 @@ static int do_merge(struct repository *r, > o.branch2 = ref_name.buf; > o.buffer_output = 2; > > - if (opts->strategy && !strcmp(opts->strategy, "ort")) { > + if (!opts->strategy || !strcmp(opts->strategy, "ort")) { > /* > * TODO: Should use merge_incore_recursive() and > * merge_switch_to_result(), skipping the call to > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] Change default merge backend from recursive to ort 2021-08-09 17:38 ` Phillip Wood @ 2021-08-09 21:01 ` Elijah Newren 0 siblings, 0 replies; 10+ messages in thread From: Elijah Newren @ 2021-08-09 21:01 UTC (permalink / raw) To: Phillip Wood Cc: Elijah Newren via GitGitGadget, Git Mailing List, Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason On Mon, Aug 9, 2021 at 10:38 AM Phillip Wood <phillip.wood123@gmail.com> wrote: ... > > === Extensibility === > > > > Being able to perform merges without touching the working tree or index > > makes it possible to create new features that were difficult with the > > old backend: > > > > * Merging, cherry-picking, rebasing, reverting in bare repositories... > > or just on branches that aren't checked out. > > Rebasing without updating the worktree for each commit is exciting. Yeah, there appear to be some interesting twists from my initial investigations so far. I may need to start some interesting discussions in the next cycle or two about what we should do here (and also for merges in bare repositories.) > I agree with others that this should be merged into next sooner rather > than later. I also agree with Peff's point about moving it into master > to get more people using it rather than sitting in next for too long. :-) > I think the sequencer changes below are easier to follow in this > version. Thanks for taking a look. > One thing I did wonder is whether there needs to be any change > to the CI scripts to ensure we keep testing both merge implementations. There did need to be such a change, but it was made previously in commit f3b964a07e ("Add testing with merge-ort merge strategy", 2021-03-20). That commit changed the default merge backend *for testing* to be merge-ort, and modified the linux-gcc job to explicitly specify recursive. This commit doesn't change the testing story, so the recursive backend will still continue to be tested with the linux-gcc tests, or whenever someone requests it with GIT_TEST_MERGE_ALGORITHM=recursive, and otherwise merge-ort will be used. > Best wishes and congratulations on an impressive achievement Thanks! ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/2] Update docs for change of default merge backend 2021-08-04 5:38 [PATCH 0/2] Switch default merge backend from recursive to ort Elijah Newren via GitGitGadget 2021-08-04 5:38 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget @ 2021-08-04 5:38 ` Elijah Newren via GitGitGadget 2021-08-04 14:26 ` Derrick Stolee 2021-08-04 14:27 ` [PATCH 0/2] Switch default merge backend from recursive to ort Derrick Stolee 2 siblings, 1 reply; 10+ messages in thread From: Elijah Newren via GitGitGadget @ 2021-08-04 5:38 UTC (permalink / raw) To: git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren, Elijah Newren From: Elijah Newren <newren@gmail.com> 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> --- Documentation/git-rebase.txt | 28 ++++----- Documentation/gitfaq.txt | 2 +- Documentation/merge-options.txt | 2 +- Documentation/merge-strategies.txt | 93 ++++++++++++++++-------------- Documentation/user-manual.txt | 2 +- 5 files changed, 67 insertions(+), 60 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 73d49ec8d91..3f1030df70e 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.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 diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index afdaeab8503..8c1f2d56751 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -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 diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index f819bd8dd68..72b53188504 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -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>:: diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 210f0f850b2..34c6c31d8e7 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -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 diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 96240598e3f..865074bed4e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -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 -- gitgitgadget ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] Update docs for change of default merge backend 2021-08-04 5:38 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget @ 2021-08-04 14:26 ` Derrick Stolee 0 siblings, 0 replies; 10+ messages in thread From: Derrick Stolee @ 2021-08-04 14:26 UTC (permalink / raw) To: Elijah Newren via GitGitGadget, git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren On 8/4/2021 1:38 AM, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@gmail.com> These updates look good to me. Mostly whole paragraphs moving and some word replacements. > subtree:: > - This is a modified recursive strategy. When merging trees A and > + This is a modified ort strategy. When merging trees A and Here is one more case where the old docs could have used quotes around "recursive" and the new ones could use quotes around "ort". Not worth a re-roll on its own. Thanks, -Stolee ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/2] Switch default merge backend from recursive to ort 2021-08-04 5:38 [PATCH 0/2] Switch default merge backend from recursive to ort Elijah Newren via GitGitGadget 2021-08-04 5:38 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget 2021-08-04 5:38 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget @ 2021-08-04 14:27 ` Derrick Stolee 2 siblings, 0 replies; 10+ messages in thread From: Derrick Stolee @ 2021-08-04 14:27 UTC (permalink / raw) To: Elijah Newren via GitGitGadget, git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren On 8/4/2021 1:38 AM, Elijah Newren via GitGitGadget wrote: > This is a reroll of my RFC series[1] to switch the default merge backend > from recursive to ort. The consensus seems to be that we should do this > immediately after the 2.33 release. > > Note that folks who want to get the old merge backend after this series can > simply set pull.twohead=recursive. (And, similarly, before this series, > those who want to try out ort in Git 2.32 or Git 2.33 can set > pull.twohead=ort.) > > Changes since the RFC version of this series: > > * Now depends on the reroll of en/merge-strategy-docs I just submitted[2]. > * Made tweaks to code and documentation suggested by Stolee, Dscho, and > Ævar I'm happy with this version (modulo a super tiny nitpick that doesn't merit a re-roll) and the docs that preceded it. I'm going to adapt my version for the microsoft/git fork to take this version and put it in our v2.33.0 release. Thanks, -Stolee ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 0/2] [RFC] Switch default merge backend from recursive to ort @ 2021-08-01 0:07 Elijah Newren via GitGitGadget 2021-08-01 0:07 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget 0 siblings, 1 reply; 10+ messages in thread From: Elijah Newren via GitGitGadget @ 2021-08-01 0:07 UTC (permalink / raw) To: git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren This is an RFC series designed to spur feedback about switching the default merge backend (reviewing the patches is of secondary importance at this point). Some questions: * Are there things others want before this series is considered for inclusion? * What kind of timeline do others think is reasonable? * Would it be beneficial to let this series sit in 'next' for an extended duration to gain more feedback? Some potentially useful context in relation to the above: * I've personally used the ort backend for well over a year * I have ~50 testers using ort as the default merge backend since Nov. 2020. * ort fixes known bugs in recursive, and there are no known regressions (more testers may change that) * ort is significantly faster than recursive * ort provides one new feature already, and enables more that are on the way * The commit message of patch 1 has more details about the last three items above So...thoughts? Elijah Newren (2): Change default merge backend from recursive to ort Update docs for change of default merge backend Documentation/git-rebase.txt | 17 ++-- Documentation/gitfaq.txt | 2 +- Documentation/merge-options.txt | 4 +- Documentation/merge-strategies.txt | 98 +++++++++++-------- .../technical/directory-rename-detection.txt | 14 +-- Documentation/user-manual.txt | 2 +- builtin/merge.c | 10 +- builtin/rebase.c | 2 +- sequencer.c | 4 +- 9 files changed, 89 insertions(+), 64 deletions(-) base-commit: eb27b338a3e71c7c4079fbac8aeae3f8fbb5c687 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1055%2Fnewren%2Fort-default-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1055/newren/ort-default-v1 Pull-Request: https://github.com/git/git/pull/1055 -- gitgitgadget ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/2] Update docs for change of default merge backend 2021-08-01 0:07 [PATCH 0/2] [RFC] " Elijah Newren via GitGitGadget @ 2021-08-01 0:07 ` Elijah Newren via GitGitGadget 2021-08-02 14:59 ` Derrick Stolee 2021-08-03 14:39 ` Elijah Newren 0 siblings, 2 replies; 10+ messages in thread From: Elijah Newren via GitGitGadget @ 2021-08-01 0:07 UTC (permalink / raw) To: git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren, Elijah Newren From: Elijah Newren <newren@gmail.com> Make multiple documentation updates to bring things up to date as we change the default merge backend... Add a section for `ort` within merge-strategies.txt; while it accepts the same flags as `recursive` (even if it ignores three of them) and is meant as a drop in replacement, it still makes sense to explicitly cover it. Change several locations in the docs that referred to `recursive` as the default merge backend, and fix a few that said or implied that only `recursive` had certain abilities (such as rename detection). Fix up some wording in directory-rename-detection.txt due to some restructurings performed while optimizing both the ort backend and the rename detection machinery. Drop the "is considered generally safe and fast" from the description of the `resolve` strategy, since that implies the other strategies are not. While such an implication may have been true in 2005 when written, it may well be that `ort` is faster today (since it does not need to recurse into all directories). Also, since `resolve` was the default for less than a year while `recursive` has been the default for a decade and a half, I think `recursive` is more battle-tested than `resolve` is. Move the description of `resolve` near `octopus` and `ours` while at it since it is no longer the default merge algorithm and hasn't been for a very long time. Signed-off-by: Elijah Newren <newren@gmail.com> --- Documentation/git-rebase.txt | 17 ++-- Documentation/gitfaq.txt | 2 +- Documentation/merge-options.txt | 4 +- Documentation/merge-strategies.txt | 98 +++++++++++-------- .../technical/directory-rename-detection.txt | 14 +-- Documentation/user-manual.txt | 2 +- 6 files changed, 78 insertions(+), 59 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 55af6fd24e2..41b68423444 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -340,9 +340,10 @@ 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. + Use merging strategies to rebase. When either the `ort` + (default) or `recursive` merge strategy is used, this allows + rebase to be aware of renames on the upstream side. This is the + 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 @@ -355,8 +356,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. + If there is no `-s` option the `ort` strategy is the default. + This implies --merge. + Because 'git rebase' replays each commit from the working branch on top of the <upstream> branch using the given strategy, using @@ -369,7 +370,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. @@ -530,7 +531,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. @@ -1219,7 +1220,7 @@ 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` +At this time, the `merge` command will *always* use the `ort` 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, diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index afdaeab8503..072bf84fa8a 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -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 diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index eb0aabd396f..72b53188504 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -112,8 +112,8 @@ 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 ('git merge-recursive' when merging a single - head, 'git merge-octopus' otherwise). + is used instead (`ort` 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 2912de706bf..6caf3fd6486 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -6,28 +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`. -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 - 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, but currently cannot 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 @@ -43,19 +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;; - 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`. - -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`. - ignore-space-change;; ignore-all-space;; ignore-space-at-eol;; @@ -84,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 @@ -105,6 +82,45 @@ subtree[=<path>];; is prefixed (or stripped from the beginning) to make the shape of two trees to match. +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. ++ +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 shorthand 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, which can be computationally much + more expensive for the `recursive` strategy than for `ort`. + 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 + and another branch you pulled from) using a 3-way merge + algorithm. It tries to carefully detect criss-cross + merge ambiguities. It cannot handle renames. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is @@ -121,13 +137,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 diff --git a/Documentation/technical/directory-rename-detection.txt b/Documentation/technical/directory-rename-detection.txt index 49b83ef3cc4..029ee2cedc5 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 diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 96240598e3f..865074bed4e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -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 -- gitgitgadget ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] Update docs for change of default merge backend 2021-08-01 0:07 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget @ 2021-08-02 14:59 ` Derrick Stolee 2021-08-03 14:39 ` Elijah Newren 1 sibling, 0 replies; 10+ messages in thread From: Derrick Stolee @ 2021-08-02 14:59 UTC (permalink / raw) To: Elijah Newren via GitGitGadget, git Cc: Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason, Elijah Newren On 7/31/2021 8:07 PM, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@gmail.com> ... > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt > index afdaeab8503..072bf84fa8a 100644 > --- a/Documentation/gitfaq.txt > +++ b/Documentation/gitfaq.txt > @@ -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 nit: I feel like quotes around "ort" would be beneficial here. It would have also helped the previous version, too, in my opinion. > 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 > diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt > index eb0aabd396f..72b53188504 100644 > --- a/Documentation/merge-options.txt > +++ b/Documentation/merge-options.txt > @@ -112,8 +112,8 @@ 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 ('git merge-recursive' when merging a single > - head, 'git merge-octopus' otherwise). > + is used instead (`ort` 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 2912de706bf..6caf3fd6486 100644 > --- a/Documentation/merge-strategies.txt > +++ b/Documentation/merge-strategies.txt > @@ -6,28 +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`. > > -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 > - 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, but currently cannot 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. nit: Quotes around "recursive" might be useful here, too. > + > -The 'recursive' strategy can take the following options: > +The 'ort' strategy can take the following options: (Like these quotes.) Other than my nits, these doc updates are solid. Thanks, -Stolee ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] Update docs for change of default merge backend 2021-08-01 0:07 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget 2021-08-02 14:59 ` Derrick Stolee @ 2021-08-03 14:39 ` Elijah Newren 1 sibling, 0 replies; 10+ messages in thread From: Elijah Newren @ 2021-08-03 14:39 UTC (permalink / raw) To: Elijah Newren via GitGitGadget Cc: Git Mailing List, Christian Couder, Derrick Stolee, Emily Shaffer, Eric Sunshine, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Phillip Wood, René Scharfe, Taylor Blau, Ævar Arnfjörð Bjarmason On Sat, Jul 31, 2021 at 6:07 PM Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> wrote: > > From: Elijah Newren <newren@gmail.com> > > Make multiple documentation updates to bring things up to date as we > change the default merge backend... Some of these changes are specific to the change in default backend, but many of them are probably useful updates prior to such a switch. I'm going to break those out into several small patches and submit them separately so they can be included in Git v2.33.0 if wanted. I'll then take the remaining changes and resubmit them after 2.33.0 along with the switch of default. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-08-09 21:01 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-04 5:38 [PATCH 0/2] Switch default merge backend from recursive to ort Elijah Newren via GitGitGadget 2021-08-04 5:38 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget 2021-08-09 17:38 ` Phillip Wood 2021-08-09 21:01 ` Elijah Newren 2021-08-04 5:38 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget 2021-08-04 14:26 ` Derrick Stolee 2021-08-04 14:27 ` [PATCH 0/2] Switch default merge backend from recursive to ort Derrick Stolee -- strict thread matches above, loose matches on Subject: below -- 2021-08-01 0:07 [PATCH 0/2] [RFC] " Elijah Newren via GitGitGadget 2021-08-01 0:07 ` [PATCH 2/2] Update docs for change of default merge backend Elijah Newren via GitGitGadget 2021-08-02 14:59 ` Derrick Stolee 2021-08-03 14:39 ` Elijah Newren
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.