git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Isabella Stephens <istephens@atlassian.com>
Cc: sunshine@sunshineco.com, szeder.dev@gmail.com,
	git@vger.kernel.org, peff@peff.net, bturner@atlassian.com,
	jacob.keller@gmail.com
Subject: Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file
Date: Fri, 27 Apr 2018 11:09:44 +0900	[thread overview]
Message-ID: <xmqq36zh1jtj.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <25cd86ff-a5c0-a968-62d2-4365e5e17a81@atlassian.com> (Isabella Stephens's message of "Fri, 27 Apr 2018 11:42:45 +1000")

Isabella Stephens <istephens@atlassian.com> writes:

> On 27/4/18 10:50 am, Junio C Hamano wrote:
>> istephens@atlassian.com writes:
>> 
>>> diff --git a/line-range.c b/line-range.c
>>> index 323399d16..023aee1f5 100644
>>> --- a/line-range.c
>>> +++ b/line-range.c
>>> @@ -47,7 +47,7 @@ static const char *parse_loc(const char *spec, nth_line_fn_t nth_line,
>>>  			else if (!num)
>>>  				*ret = begin;
>>>  			else
>>> -				*ret = begin + num;
>>> +				*ret = begin + num ? begin + num : -1;
>> 
>> When parsing "-L<something>,-20" to grab some lines before the line
>> specified by <something>, if that something happens to be line #20,
>> this gives -1 to *ret.  If it is line #19, *ret becomes -1, and if
>> it is line #18 or before, *ret becomes -2, -3, ...
>> 
>> Is that what we really want here?  It is disturbing that only line
>> #19 and #20 are treated identically in the above example.  If it
>> were "if going backwards by -num lines from begin goes beyond the
>> beginning of the file, clip it to the first line", I would
>> understand it, but as written, I am not sure what the code is trying
>> to do.
>> 

[administrivia] Do not top-post, but cull the context to leave
enough to remind readers what the discussion was about.

> My intention was to modify existing behaviour as little as possible,
> but I agree clipping to the first line makes a lot more sense. That
> raises the question though, do we clip to 1 and treat -L,-n as a valid
> input, or clip to -1 so that this case be detected?

Maybe I misread the previous discussion and/or your cover letter,
but I have been assuming that you are trying to avoid failing the
command in a useless way (e.g. when the file has only ~800 lines but
the user does not know exactly how many, instead of letting -L1,820 
to fail with "the file only has 815 lines", pretend that the -L1,815
was given) and instead give a reasonable fall-back behaviour.

And to be consistent with that world view, I would have expected
that the meaning of -L<something>,-20 to be updated from "fail if
<something> is before line #20, or show 20 lines leading to
<something>" to "show lines leading to <something>, up to 20 lines
but it is OK if there aren't enough lines in the file to show that
many".

So the answer to the question probably depends on what happens when
"this case is detected" by returning -1 from here.  Do we detect and
fail?  That would defeat the overall theme of these patches.  Do we
detct and warn but continue?  That may be sensible in theory, but in
practice, especially where this "the users may not know how many
lines exactly the blob has, so do not force them to count" matters,
"blame" and "log" would show a lot of output that is sent to the
pager, so the warning message may not be shown in a noticeable way.
Compared to that, "pretend as if the first line was specified and go
on" looks like we have one fewer thing to worry about ;-)



  reply	other threads:[~2018-04-27  2:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-26  2:19 [PATCH] blame: add --fuzzy-lines command line option Isabella Stephens
2017-10-26  6:15 ` Junio C Hamano
2017-10-26  7:01   ` [PATCH v2] blame: prevent error if range ends past end of file Isabella Stephens
2017-10-26  8:48     ` Jacob Keller
2017-10-26 22:50       ` Isabella Stephens
2017-10-26 15:31     ` SZEDER Gábor
2017-10-26 23:37       ` Isabella Stephens
2017-10-27  0:56       ` [PATCH v3] " Isabella Stephens
2017-10-27  1:58         ` Junio C Hamano
2017-10-27  2:01           ` Junio C Hamano
2017-10-27  6:18           ` Isabella Stephens
2017-10-27  6:56             ` Eric Sunshine
2018-04-26  7:45               ` [PATCH v4 0/2] blame and log: " istephens
2018-04-26  7:45                 ` [PATCH v4 1/2] blame: " istephens
2018-04-27  0:50                   ` Junio C Hamano
2018-04-27  1:42                     ` Isabella Stephens
2018-04-27  2:09                       ` Junio C Hamano [this message]
2018-04-27  4:15                         ` Isabella Stephens
2018-05-02  2:47                           ` Junio C Hamano
2018-05-29  5:30                             ` [PATCH v5 0/2] blame and log: " istephens
2018-05-29  5:30                               ` [PATCH] blame: " istephens
2018-05-30  8:45                                 ` Eric Sunshine
2018-05-31  5:07                                   ` Isabella Stephens
2018-05-29  5:30                               ` [PATCH] log: prevent error if line " istephens
2018-05-30  8:59                                 ` Eric Sunshine
2018-04-26  7:45                 ` [PATCH v4 2/2] " istephens
2017-10-26  7:08   ` [PATCH] blame: add --fuzzy-lines command line option Isabella Stephens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq36zh1jtj.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=istephens@atlassian.com \
    --cc=jacob.keller@gmail.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).