Re: [BUG?] blame: Odd -L 1,+0 behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 16, 2010, 22:33 UTC
Message-ID: <7vmxtrqcpl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTinSO3S4hjuvzSOfEBwBEL8_amk7uM2-_LKMtE8k@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 5 quoted lines

>> As a side effect of the internal implementation of this logic -L 5,3
>> means the same thing as -L 3,5 but that is not an intended nor
>> documented behaviour.
>
> How should L 5,3 and 3,5 work? Should the former give an error?

"-L 3,5" would choose "lines 3,4, and 5" (both ends inclusive). Currently "-L 5,3" does the same thing but as I said, that is not an intended nor documented behaviour, and if you are tackling this area to tighten the parsing and error diagnosis, I think it is reasonable to error it out.

Show 10 quoted lines

>>> Shouldn't this either print nothing, er be an error:
>> (multiple)
>>
>> The parsing code is lax in the sense that rejecting nonsensical input like
>> "-L 10,-100" and "-L 2,+0" as an error was not considered a primary goal.
>> The only error checking it does is to make sure it does not parse numbers
>> that it cannot use (i.e. start from line 30 in a file that does not have
>> that many lines).
>
> Do you want a patch to make it less lax?

Be my guest ;-)  Thanks.