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

Maarten Ackermans [off-list ref] 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