Re: [PATCH/RFC] blame: accept multiple -L ranges

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH/RFC] blame: accept multiple -L ranges

From: Thomas Rast <hidden>
Date: 2016-06-15 22:58:03

Junio C Hamano [off-list ref] writes:
Eric Sunshine [off-list ref] writes:
quoted
On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast [off-list ref] wrote:
quoted
Junio C Hamano [off-list ref] writes:
quoted
 (2) In the ranges "-L <anything>,/B/ -L /C/,<anything>", the
     beginning of the second range is found by choosing C that comes
     _after_ the end of the previous range (/B/ may choose either
     the second or the 4th line, and the only C that comes after
     either of them is the 5th line and that is where the second
     range should begin, not at the beginning of the file).  The
     same for "-L 1,3 -L /C/" (only C that comes after 3 is eligible
     to be the beginning of the second range).
So passing several -L arguments does not blame the union of what each
argument would blame individually?  Doesn't that make it rather harder
to explain?
I don't think Junio meant to imply that. Collecting the blame ranges
can/should be a distinct step from coalescing them. Junio is saying
that an -L /re/ range search should start after the maximum line
number already specified by any preceding range.
I am not sure if I want "maximum specified so far". I meant "start
searching at the last location", e.g.

	-L 100,200 -L 4,6 -L /A/,+20

would want to find the first A after line 6, not after line 200.
Ok, so my point (in new words, since the old one was apparently too
terse) is:

If you define it that way, the output of

  git blame -L 4,6; git blame -L /A/,+20

is significantly different from

  git blame -L 4,6 -L /A/,+20

Not just in the presentation or any possible coalescing, but in the
meaning of the ranges.

Do you really want to make it that way?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH/RFC] blame: accept multiple -L ranges

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:58:03

Thomas Rast wrote:
If you define it that way, the output of

  git blame -L 4,6; git blame -L /A/,+20

is significantly different from

  git blame -L 4,6 -L /A/,+20

Not just in the presentation or any possible coalescing, but in the
meaning of the ranges.
I can see both meanings being useful.  I suspect that the "restart at
the top of the file for each LHS regex" meaning would be more useful,
though.

Thanks,
Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help