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

[Sean Allred <allred.sean@gmail.com>]

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

> 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