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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Whether or not that is Git's definition of a breaking change, the
message of the commit in question acknowledges that the commands in
the "log" family are the oldest in the system:

> The "rev-list" and other commands in the "log" family, being the oldest part of the system, use their own custom argument parsers, and integer values of some options are parsed with atoi(), which allows a non-digit after the number (e.g., "1q") to be silently ignored. As a natural consequence, an argument that does not begin with a digit (e.g., "q") silently becomes zero, too.

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.

On Wed, Feb 21, 2024 at 8:55 PM Kristoffer Haugsbakk
<code@xxxxxxxxxxxxxxx> wrote:
>
> On Wed, Feb 21, 2024, at 14:32, Maarten Ackermans wrote:
> > Hi all,
> >
> > I would like to report a breaking change with "git log -n" introduced
> > in 2.43 that's causing some trouble:
> > https://github.com/git/git/commit/71a1e94821666909b7b2bd62a36244c601f8430e#diff-380c4eac267b5af349ace88c78a2b004a16ed20c2b605c76827981063924bbf9R2222
> >
> > 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.
> >
> > See https://github.com/intuit/auto/issues/2425#issuecomment-1956557071
> > for the impact.
> >
> > Best regards,
> >
> > Maarten Ackermans
>
> I don’t see how this is a breaking change considering the range is not
> documented.
>
> --
> Kristoffer Haugsbakk
>





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux