Re: [PATCH v2 08/16] line-range: teach -L/RE/ to search relative to anchor point
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 6, 2013, 21:44 UTC
- Message-ID
- <7vwqnyebpv.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1375797589-65308-9-git-send-email-sunshine@sunshineco.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
Show 42 quoted lines
> Range specification -L/RE/ for blame/log unconditionally begins
> searching at line one. Mailing list discussion [1] suggests that, in the
> presence of multiple -L options, -L/RE/ should search relative to the
> endpoint of the previous -L range, if any.
>
> Teach the parsing machinery underlying blame's and log's -L options to
> accept a start point for -L/RE/ searches. Follow-up patches will upgrade
> blame and log to take advantage of this ability.
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/229755/focus=229966
>
> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
> ---
> builtin/blame.c | 2 +-
> line-log.c | 2 +-
> line-range.c | 30 ++++++++++++++++++++++++++----
> line-range.h | 5 ++++-
> 4 files changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 2f4d9e2..7b084d8 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -2479,7 +2479,7 @@ parse_done:
> for (range_i = 0; range_i < range_list.nr; ++range_i) {
> long bottom, top;
> if (parse_range_arg(range_list.items[range_i].string,
> - nth_line_cb, &sb, lno,
> + nth_line_cb, &sb, lno, 1,
> &bottom, &top, sb.path))
> usage(blame_usage);
> if (lno < top || ((lno || bottom) && lno < bottom))
> diff --git a/line-log.c b/line-log.c
> index bdadf35..38f827b 100644
> --- a/line-log.c
> +++ b/line-log.c
> @@ -591,7 +591,7 @@ parse_lines(struct commit *commit, const char *prefix, struct string_list *args)
> cb_data.line_ends = ends;
>
> if (parse_range_arg(range_part, nth_line, &cb_data,
> - lines, &begin, &end,
> + lines, 1, &begin, &end,This one feeds "1" to anchor, which in turn is given to parse_loc as "-1" and then (after bypassing the <end> part support) its sign flipped once again to become "begin=1" in parse_loc(). Then we run regexp search starting from (1-based) 1st line, retaining the "always scan from the beginning" behaviour in this step in the series.
OK, looks sensible.