Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2018, 02:47 UTC
Message-ID: <xmqqzi1iwz7l.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <dee9083d-0745-6b98-fe5e-fc19d2a5bb9a@atlassian.com>

Isabella Stephens <istephens@atlassian.com> writes:

Show 7 quoted lines

> This is the existing behaviour. -L10,-20 for example will blame the
> first 10 lines of a file, it will not fail. My patch doesn't change
> this. The case I am discussing is -L,-20 which at the moment blames
> the first line of the file. Trying to go backwards from the start of
> a file should be considered invalid, in my opinion, however I don't
> feel strongly about it - I don't expect this case is common in 
> practice.

I tend to think that -L,-20 is a sloppy spelling of -L1,-20 (i.e. anything omitted gets reasonable default, and for something that specifies both ends, i.e. "<begin>,<end>", the beginning and the end of the file would be such reasonable default, respectively), and as such I would imagine that the user would expect the same behaviour as -L1,-20. If the longhand version gives only the first line (i.e. show up to 20 lines ending at line #1), I'd say that sounds sensible.

Or does -L1,-20 show nothing and consider the input invalid? If so, then sure, -L,-20 should also be an invalid input.