On Tue, Jul 20, 2010 at 11:46 PM, Bo Yang <struggleyb.nku@xxxxxxxxx> wrote: > 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] Forget [1]: gmane.comp.version-control.git:142900 -- 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