Re: [PATCH v3 05/13] parse the -L options
- From
Bo Yang <struggleyb.nku@gmail.com>
- Date
- Jul 20, 2010, 15:46 UTC
- Message-ID
- <AANLkTinXDRV_Ikd-hoGoWPZmn1Tp0NYHoumaqthydsuw@mail.gmail.com>
- In-Reply-To
- <201007200951.56218.trast@student.ethz.ch>
On Tue, Jul 20, 2010 at 3:51 PM, Thomas Rast <trast@student.ethz.ch> wrote:
Show 29 quoted lines
> Junio C Hamano wrote: >> Thomas Rast <trast@student.ethz.ch> writes: >> > 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. >> >> 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). > > AFAICT this is not a conceptual requirement, only one of the current > implementation/option parsing. [Bo, how hard would it be to remove > this requirement?] > > 'git log --follow', if it were ever unbroken, would have much the same > problem that while technically allowing more than one starting point, > using that is only possible if the starting filename happens to agree > on all of them.
I think Junio here did not ask for 'git log -L' to support multiple starting commits. [1] Considering the arguments you give below, I am in support of put it in 'git log -L' as what we do, now.
-- Regards! Bo ---------------------------- My blog: http://blog.morebits.org Why Git: http://www.whygitisbetterthanx.com/