From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 02 May 2018 02:47:26 GMT
Subject: Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file
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:

> 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.