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