Re: Breaking change with "git log -n" since 2.43

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Feb 21, 2024, 15:32 UTC
Message-ID: <310b2dcf-df69-4984-9a92-b8485e0f715b@app.fastmail.com>
In-Reply-To: <CAB=tB2uZb+8QLmrk_tK5PKJtDE=RmBr=eBBb7U7ygSmkFoXvWg@mail.gmail.com>

On Wed, Feb 21, 2024, at 16:07, Maarten Ackermans wrote:

Show 5 quoted lines

> I would suggest displaying a warning in case of invalid input (such as
> this out of range error), and to fall back to output all as if the
> "-n" flag was unspecified. If more strict handling is still desired,
> it could instead be a deprecation warning with a grace period, giving
> applications some time to update their git usage.

From 71a1e9482:

  “ As a natural consequence, an argument that does not begin with a
    digit (e.g., "q") silently becomes zero, too.

It sounds like the non-breaking behavior for non-number input like `q` is to silently become `0`.[1] But then that too-large number input would also become `0`, which doesn’t help for that JavaScript application/library. Unless `strtol_i` is able to differentiate between different errors by returning different negative numbers?

† 1: Or else you risk breaking usages where they rely on bad input
    becoming `0`

-- 
Kristoffer Haugsbakk