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:
 (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?

In any case, if you define it like that for blame, log -L should be
changed to match.

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

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

From: Eric Sunshine <hidden>
Date: 2016-06-15 22:58:03

On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast [off-list ref] wrote:
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. Once all input ranges
are collected, they can be coalesced. (If a -L /re/ range happens to
be coalesced with or into some other range, that's fine: you're still
seeing blame output for the requested lines.)

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