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

From: Sean Allred <allred.sean@gmail.com>
Date: Feb 21, 2024, 15:34 UTC
Message-ID: <m0v86hbze6.fsf@epic96565.epic.com>
In-Reply-To: <CAB=tB2vKj45yr3amMbhv_dYBdqYOtoiMS7Ecx4WO1TE2STHEsA@mail.gmail.com>

Maarten Ackermans <maarten.ackermans@gmail.com> writes:

Show 7 quoted lines

> I think you’re right, so reinstating the original behavior with a
> deprecation warning would be more prudent.
>
> After the grace period, if invalid input is given, fall back to output
> all with a warning. Or you can go the strict route again and crash
> with a fatal error (hard to imagine an actual use case for such a
> large, specific number, anyway).

To be clear, I'm not advocating we go back to the prior behavior. I'm just clarifying what your proposal would mean.

I don't pretend to have any nuanced understanding of how the Git project handles situations like this, but IMHO, I would have to fall back to the principle of least surprise. Rejecting invalid input is not a crash -- it is a useful guardrail to ensure the user and the computer agree on what's been requested / what's going to happen.

Again, I don't have any experience with how similar situations are handled here, but I would contend that the behavior you describe as the breaking behavior is the behavior that should exist long-term.

-- Sean Allred