Re: [PATCH 09/10] Documentation: add coverage of the `ort` merge strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Elijah,

On Tue, 3 Aug 2021, Elijah Newren via GitGitGadget wrote:

> From: Elijah Newren <newren@xxxxxxxxx>
>
> Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> ---
>  Documentation/git-rebase.txt       |  7 ++++---
>  Documentation/merge-strategies.txt | 14 ++++++++++++++
>  2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index b4429954480..3e112011c6f 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 `recursive`
> +	(default) or `ort` merge strategy is used, this allows rebase
> +	to be aware of renames on the upstream side.  This is the
> +	default.

Since this now talks about two merge strategies, I think "This is the
default" needs to specify which of the two strategies 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
> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
> index d21dbd1e051..d13d4a29875 100644
> --- a/Documentation/merge-strategies.txt
> +++ b/Documentation/merge-strategies.txt
> @@ -96,6 +96,20 @@ 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.

Probably `diff-algorithm=histogram` should also be enclosed within
backticks.

Thanks,
Dscho

> +
>  resolve::
>  	This can only resolve two heads (i.e. the current branch
>  	and another branch you pulled from) using a 3-way merge
> --
> gitgitgadget
>
>




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux