Re: [PATCH v3 05/13] parse the -L options

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 19, 2010, 23:53 UTC
Message-ID: <7veiezni4m.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201007200048.18284.trast@student.ethz.ch>

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

Show 21 quoted lines

> Junio C Hamano wrote:
>> It almost feels as if you want to have something more like
>> 
>>     -L <begin>,<end>[,<path>]
>> 
>> where <path> is mandatory for the first use of -L (i.e. missing ,<path>
>> means the same path from the previous -L that has one) to make it clear
>> that this is completely different from the normal pathspec.
>
> I think that would just needlessly break the analogy to git-blame.[0]
> With the current code,
>
>   git blame -L 2,3 <path>
>   git log -L 2,3 <path>
>
> work the same.  Multiple -L options could be retrofitted to git-blame,
> making
>
>   git {blame,log} -L 2,3 -L 4,5 <path>
>
> work as expected.

I like the general direction, but I am not sure how far we want to take that analogue with blame, though.

For example, Bo's "log -L" thing also works on more than one path, no? I suspect it might be be reasonable to teach "blame" to annotate more than one path (with ranges) the same way. There is no technical limitation in the underlying scoreboard mechanism to prevent it from happening.

Very similar to "blame" but quite differently from any normal "log" operation, "log -L" allows only one positive commit (starting point).

Perhaps these argue that this new feature shouldn't be a new option of "log" at the UI level after all; rather, I wonder if this should be better presented as a new mode of "blame" (e.g. "blame --log", unlike showing "cvs annotate" like output, shows history like "git log" does).

I _think_ I've already said the above at least a few times, though.