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

From: Jeff King <peff@peff.net>
Date: Feb 21, 2024, 17:51 UTC
Message-ID: <20240221175153.GD634809@coredump.intra.peff.net>
In-Reply-To: <CAB=tB2vB0LbP=DznSqTFYHCRxDxd6U=Q+P33yeBzGssq2eK1vA@mail.gmail.com>

On Wed, Feb 21, 2024 at 08:32:46PM +0700, Maarten Ackermans wrote:

Show 9 quoted lines

> To reproduce, the command `git log -n 9007199254740991` fails on
> 2.43.2, whereas it didn't on 2.42.0. This specific number corresponds
> to the Number.MAX_SAFE_INTEGER (2^53 - 1) in JavaScript (docs:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER).
> The max value that is supported now is a signed 32-bit integer (2^31 -
> 1).
> 
> I suppose git simply ignored the extra digits of the number, as the
> commit message describes.

The max value was always a signed 32-bit integer. The extra digits weren't ignored, but rather there was integer truncation at the C level. I believe that is technically implementation defined by the compiler, though in practice your value would generally become -1.

But passing, say, 9007199254740993 would give quite unexpected results (the truncated value is "1" and we'd show only a single commit).

So I'm sympathetic that your specific number used to work and now doesn't, but it feels like going back to the truncating behavior is a step in the wrong direction.

If the goal is to have no limit at all, then passing an explicit "-1" works, though I don't think that's a documented outcome. I do suspect that we _would_ try to keep that historical behavior, as there is no other way to cancel a previous "-n" or otherwise say "no limit". It might be worth formalizing that with documentation and a test.

-Peff