From: Derrick Stolee <stolee@gmail.com>
To: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: "Christian Couder" <chriscool@tuxfamily.org>,
"Derrick Stolee" <dstolee@microsoft.com>,
"Emily Shaffer" <emilyshaffer@google.com>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"Jeff King" <peff@peff.net>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Jonathan Tan" <jonathantanmy@google.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Phillip Wood" <phillip.wood@dunelm.org.uk>,
"René Scharfe" <l.s.r@web.de>, "Taylor Blau" <me@ttaylorr.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Elijah Newren" <newren@gmail.com>
Subject: Re: [PATCH 2/2] Update docs for change of default merge backend
Date: Mon, 2 Aug 2021 10:59:12 -0400 [thread overview]
Message-ID: <4f223333-7cbb-2304-2e81-dc91a3281241@gmail.com> (raw)
In-Reply-To: <35490397590ae4d39ba98c7eb206bfadc22ddf35.1627776462.git.gitgitgadget@gmail.com>
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
next prev parent reply other threads:[~2021-08-02 14:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 0:07 [PATCH 0/2] [RFC] Switch default merge backend from recursive to ort Elijah Newren via GitGitGadget
2021-08-01 0:07 ` [PATCH 1/2] Change " Elijah Newren via GitGitGadget
2021-08-02 15:55 ` Ævar Arnfjörð Bjarmason
2021-08-02 16:33 ` Elijah Newren
2021-08-02 22:46 ` Johannes Schindelin
2021-08-03 1:04 ` Elijah Newren
2021-08-03 2:56 ` Philippe Blain
2021-08-03 3:39 ` Elijah Newren
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 [this message]
2021-08-03 14:39 ` Elijah Newren
2021-08-02 15:05 ` [PATCH 0/2] [RFC] Switch default merge backend from recursive to ort Derrick Stolee
2021-08-02 16:27 ` Elijah Newren
2021-08-02 18:03 ` Derrick Stolee
2021-08-03 15:56 ` Jeff King
2021-08-03 16:57 ` Elijah Newren
2021-08-03 17:13 ` Jeff King
2021-08-03 22:08 ` Junio C Hamano
2021-08-03 22:37 ` Jeff King
2021-08-03 22:48 ` Elijah Newren
2021-08-03 22:46 ` Elijah Newren
-- strict thread matches above, loose matches on Subject: below --
2021-08-04 5:38 [PATCH 0/2] " 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:26 ` Derrick Stolee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f223333-7cbb-2304-2e81-dc91a3281241@gmail.com \
--to=stolee@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=dstolee@microsoft.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=jrnieder@gmail.com \
--cc=l.s.r@web.de \
--cc=me@ttaylorr.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).