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

From: Maarten Ackermans <maarten.ackermans@gmail.com>
Date: Feb 21, 2024, 15:07 UTC
Message-ID: <CAB=tB2uZb+8QLmrk_tK5PKJtDE=RmBr=eBBb7U7ygSmkFoXvWg@mail.gmail.com>
In-Reply-To: <m04je1dhdx.fsf@epic96565.epic.com>

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.

On Wed, Feb 21, 2024 at 9:25 PM Sean Allred <allred.sean@gmail.com> wrote:

Show 13 quoted lines

>
>
> Maarten Ackermans <maarten.ackermans@gmail.com> writes:
> > Applications that have been relying on undocumented features and
> > limits since they were introduced, now face a hard crash: "fatal:
> > '9007199254740991': not an integer". Regardless of whether this is an
> > improvement for future implementations, a crash in existing ones is a
> > suboptimal experience at the least.
>
> What behavior would you propose instead?
>
> --
> Sean Allred