Re: [PATCH] diff: avoid misleading statement about -l option

On Wed, Aug 12, 2026 at 7:22 AM Junio C Hamano [off-list ref] wrote:

"Elijah Newren via GitGitGadget" [off-list ref] writes:

quoted

From: Elijah Newren <redacted>

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

quoted

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?