From: Bo Yang Date: Tue, 20 Jul 2010 15:47:44 GMT Subject: Re: [PATCH v3 05/13] parse the -L options Message-ID: In-Reply-To: On Tue, Jul 20, 2010 at 11:46 PM, Bo Yang wrote: > On Tue, Jul 20, 2010 at 3:51 PM, Thomas Rast wrote: >> Junio C Hamano wrote: >>> Thomas Rast writes: >>> > I think that would just needlessly break the analogy to git-blame.[0] >>> > With the current code, >>> > >>> >   git blame -L 2,3 >>> >   git log -L 2,3 >>> > >>> > 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] Forget [1]: gmane.comp.version-control.git:142900 -- Regards! Bo ---------------------------- My blog: http://blog.morebits.org Why Git: http://www.whygitisbetterthanx.com/