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

[Jeff King <peff@peff.net>]

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

> 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