diff: avoid misleading statement about -l option

[newren]

Changes since v1:

• Fixed author to match signoff
• Simplified the wording a bit, along the lines of Junio's suggestion

[newren]

/submit

[gitgitgadget]

Submitted as pull.2035.git.1786516958048.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2035/newren/diff-l-option-doc-v1

To fetch this version to local tag pr-2035/newren/diff-l-option-doc-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2035/newren/diff-l-option-doc-v1

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@github.com>
>
> In commit 6623a528e00b (doc: clarify documentation for rename/copy
> limits, 2021-07-15), the wording around rename limit options and config
> variables were updated to point out that only the quadratic portion of
> rename detection (or "exhaustive portion of rename/copy detection" as
> used in that commit) was limited by these options, because exact rename
> detection and basename-guided rename detection (which both run in time
> linear in the number of files) still run before this limit is checked.
>
> However, the short help message wasn't updated at the time; update it
> too.

However this is an end-user facing message.  Can we make it more
easier to understnad by being less precise?  "limit to exact
rename/copy if ..." or something?

[gitgitgadget]

Elijah Newren wrote on the Git mailing list (how to reply to this email):

On Wed, Aug 12, 2026 at 7:22 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Elijah Newren <newren@github.com>

Oops, I had author != committer (and author != signoff).  I'll fix
that up and send in a .mailmap entry too.

> > In commit 6623a528e00b (doc: clarify documentation for rename/copy
> > limits, 2021-07-15), the wording around rename limit options and config
> > variables were updated to point out that only the quadratic portion of
> > rename detection (or "exhaustive portion of rename/copy detection" as
> > used in that commit) was limited by these options, because exact rename
> > detection and basename-guided rename detection (which both run in time
> > linear in the number of files) still run before this limit is checked.
> >
> > However, the short help message wasn't updated at the time; update it
> > too.
>
> However this is an end-user facing message.  Can we make it more
> easier to understnad by being less precise?  "limit to exact
> rename/copy if ..." or something?

Maybe if we replace "exact" with either "cheap" or "linear"?

   "limit to cheap rename/copy detection if the number of rename/copy
targets exceeds this value" ?

That would also tie in with the documentation for -l:

`-l<num>`::
    The `-M` and `-C` options involve some preliminary steps that
    can detect subsets of renames/copies cheaply, followed by an
    exhaustive fallback portion that compares all remaining
    unpaired destinations to all relevant sources.

Since there are two cheap preliminary steps -- "exact" and
"basename-guided" rename detection -- using "cheap" correctly covers
both.  Does that sound reasonable?

[gitgitgadget]

User Elijah Newren <newren@gmail.com> has been added to the cc: list.

[newren]

/submit

[gitgitgadget]

Submitted as pull.2035.v2.git.1786673186855.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2035/newren/diff-l-option-doc-v2

To fetch this version to local tag pr-2035/newren/diff-l-option-doc-v2:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2035/newren/diff-l-option-doc-v2