git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Thomas Rast <tr@thomasrast.ch>
Subject: Re: [PATCH 2/2] Documentation/git-log: mention that line-log regex must match in starting revision
Date: Wed, 18 Dec 2019 05:55:25 -0500	[thread overview]
Message-ID: <d8e753ec-2835-331f-99de-35a4a5369b48@gmail.com> (raw)
In-Reply-To: <147443E8-EA04-45D2-B3BC-D879A5FFECDC@gmail.com>

On 12/17/2019 10:28 PM, Philippe Blain wrote:
> 
>> Le 17 déc. 2019 à 13:16, Junio C Hamano <gitster@pobox.com> a écrit :
>> Even when you specify <start> or <end> as a line number, they must
>> exist in the starting revision or it would be a fatal error.  If we
>> are clarifying with this patch for completeness, I think we should
>> also mention it together.  
...
>     git log -L 300,2000000085:Documentation/git-log.txt 
> errors out:
>     fatal: file Documentation/git-log.txt has only 239 lines

This case seems important enough to include what it means to "match".

Specifically, the range must match at least one line in the file.

> But 
>     git log -L 300,-2000000085:Documentation/git-log.txt
> does not error out and shows the history for the whole file. Also,
>     git log -L 1,-2000000085:Documentation/git-log.txt
> does not error out and gives the history for the first line.

Negative numbers in the ranges are a bit strange to include, and the
large magnitude you include here seems unnecessary for the test.
However, it appears that we do store signed values in the line-log
machinery:

/* A range [start,end].  Lines are numbered starting at 0, and the
 * ranges include start but exclude end. */
struct range {
	long start, end;
};

Perhaps these should be replaced with an unsigned value instead,
just to be clear that negative values do not make sense in this
context?

Or rather, do we want to enforce start < end if they are to be
valuable? We apparently do assert() this in
range_set_check_invariants() for all that does.

The current behavior of showing only the first line
is a strange byproduct of allowing these odd ranges, but we may
want to keep it for consistency. That would imply we allow
start <= end, and auto-correct these negative values to have
end = start. (This does not fix the 300,-1 case, but that
is strange enough to be considered a bug, right?)

Thanks,
-Stolee


  reply	other threads:[~2019-12-18 10:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17  5:07 [PATCH 0/2] Improve line log documentation Philippe Blain via GitGitGadget
2019-12-17  5:07 ` [PATCH 1/2] Documentation/git-log: document accepted line-log diff formats Philippe Blain via GitGitGadget
2019-12-17 11:33   ` SZEDER Gábor
2019-12-18  2:44     ` Philippe Blain
2019-12-17 15:33   ` Derrick Stolee
2019-12-18  2:47     ` Philippe Blain
2019-12-17  5:07 ` [PATCH 2/2] Documentation/git-log: mention that line-log regex must match in starting revision Philippe Blain via GitGitGadget
2019-12-17 15:34   ` Derrick Stolee
2019-12-17 18:16     ` Junio C Hamano
2019-12-18  3:28       ` Philippe Blain
2019-12-18 10:55         ` Derrick Stolee [this message]
2019-12-18 11:49           ` SZEDER Gábor
2019-12-18 17:59           ` Junio C Hamano
2019-12-26 17:46             ` Philippe Blain
2019-12-18 11:09         ` SZEDER Gábor
2019-12-26 17:43 ` [PATCH v2 0/2] Improve line log documentation Philippe Blain via GitGitGadget
2019-12-26 17:43   ` [PATCH v2 1/2] doc: log, gitk: document accepted line-log diff formats Philippe Blain via GitGitGadget
2019-12-26 17:43   ` [PATCH v2 2/2] doc: log, gitk: line-log arguments must exist in starting revision Philippe Blain via GitGitGadget

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=d8e753ec-2835-331f-99de-35a4a5369b48@gmail.com \
    --to=stolee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=tr@thomasrast.ch \
    /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).