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

On Wed, Aug 12, 2026 at 7:22 AM Junio C Hamano <[email protected]> wrote:
>
> "Elijah Newren via GitGitGadget" <[email protected]> writes:
>
> > From: Elijah Newren <[email protected]>

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?