Thomas Rast writes:
> I'll just leave it at that and let you decide what to do (presumably go
> ahead as you already outlined). I've never actually ever used multiple
> -L in the same log/blame invocation, anyway.
Nobody has ;-).
It is just between my "I often wished while looking at 'less foo
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Eric Sunshine 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
Thomas Rast writes:
> Eric Sunshine 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 +
Eric Sunshine 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
> t
On Tue, Jul 9, 2013 at 4:25 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> It would be more general to support "follow the second match to /A/"
>> *independent* of whether the first match is also followed. I think your
>> proposal only allows the second to be followed if the first is
Thomas Rast writes:
> But still, log -L should then be changed to match this behavior (for all
> args affecting a single file). Currently it always does the scan for
> the start of the range from line 1 of the file.
Thanks, I think that makes sense.
--
To unsubscribe from this list: send the li
Junio C Hamano writes:
> Thomas Rast writes:
>
>> 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
Michael Haggerty writes:
> It would be more general to support "follow the second match to /A/"
> *independent* of whether the first match is also followed. I think your
> proposal only allows the second to be followed if the first is also
> followed. Therefore it seems to me that your wish is
On 07/09/2013 09:31 PM, Junio C Hamano wrote:
> Thomas Rast writes:
>
>> 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,
Thomas Rast writes:
> 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
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
Junio C Hamano writes:
> Eric Sunshine writes:
>
>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>>> Junio C Hamano writes:
>>>
(2) In the ranges "-L ,/B/ -L /C/,", the
beginning of the second range is found by choosing C that comes
_after_ the end of the previo
On Tue, Jul 9, 2013 at 2:55 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>>> Junio C Hamano writes:
>>>
(2) In the ranges "-L ,/B/ -L /C/,", the
beginning of the second range is found by choosing C that comes
Thomas Rast writes:
> Junio C Hamano writes:
>
>> (2) In the ranges "-L ,/B/ -L /C/,", 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 a
Eric Sunshine writes:
> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>> Junio C Hamano writes:
>>
>>> (2) In the ranges "-L ,/B/ -L /C/,", the
>>> beginning of the second range is found by choosing C that comes
>>> _after_ the end of the previous range (/B/ may choose either
>>
On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
> Junio C Hamano writes:
>
>> (2) In the ranges "-L ,/B/ -L /C/,", 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 lin
Junio C Hamano writes:
> (2) In the ranges "-L ,/B/ -L /C/,", 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
On Tue, Jul 9, 2013 at 12:39 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> As implemented by this patch, the behavior of git-blame with multiple
>> -L's is consistent with that of git-log with multiple -L's. The
>> implemented behavior feels intuitive to me, but I can see how the
>> beha
Eric Sunshine writes:
> As implemented by this patch, the behavior of git-blame with multiple
> -L's is consistent with that of git-log with multiple -L's. The
> implemented behavior feels intuitive to me, but I can see how the
> behavior you suggest could feel intuitive to others.
>
> If I re-do
[Added Cc:Thomas Rast]
On Sun, Jul 7, 2013 at 5:58 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> git-blame accepts only zero or one -L option. Clients requiring blame
>> information for multiple disjoint ranges are therefore forced either to
>> invoke git-blame multiple times, once for
Eric Sunshine writes:
> git-blame accepts only zero or one -L option. Clients requiring blame
> information for multiple disjoint ranges are therefore forced either to
> invoke git-blame multiple times, once for each range, or only once with
> no -L option to cover the entire file, which can be c
git-blame accepts only zero or one -L option. Clients requiring blame
information for multiple disjoint ranges are therefore forced either to
invoke git-blame multiple times, once for each range, or only once with
no -L option to cover the entire file, which can be costly. Teach
git-blame to accept
22 matches
Mail list logo
