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

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@inf.ethz.ch> writes:

> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> The proposal currently is only for "-L /RE/,whatever" to behave in a
>> relative fashion, beginning the search at the end of the last range
>> specified via -L (or line 1 if there is no previous -L).
>>
>> Would it also make sense to support "-L +N,whatever" as relative to
>> the end of the last range specified via -L (or 1 if none).
>
> Sounds reasonable.
>
> I'm still not sure I am super-happy with /RE/ always being relative,
> though I see Junio's problem space as something worth solving.  How does
> it interact with -L:RE?  Do you now have to know in what order the
> functions appear in the source to correctly specify -L:foo -L:bar or
> similarly, -L/foo/,/^}/ -L/bar/,/^}/?  What if we supported +/RE/ as the
> relative version?

Two gripes I have are:

 (1) That sounds like making common things more cumbersome to ask.

 (2) In "-L /RE1/,/RE2/", you do not have to say +/RE2/ (and you
     shouldn't have to).  /RE3/ without any magic that starts
     searching after the last match in "-L /RE1/,/RE2/ -L /RE3/,+4"
     feels a lot more consistent than requiring a prefix plus.

I am OK if you made /RE/, which starts searching immediately after
the last match, wrap around and continue the search at the beginning
upon finding nothing through the end of the file (and make sure you
stop if you passed the last match again).  That would solve your "I
have two functions, and I can give them in any order", while keeping
the consistency with "In /RE1/,/RE2/, the latter is already relative
to the former".