On Tue, Jul 20, 2010 at 3:51 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > Junio C Hamano wrote: >> Thomas Rast <trast@xxxxxxxxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html