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
