From: Jonathan Nieder Date: Sun, 09 May 2010 21:06:54 GMT Subject: Re: Multiple line ranges and files in line level history browser Message-ID: <20100509210654.GA1637@progeny.tock> In-Reply-To: Hi, Bo Yang wrote: > git log -L1,8 -L45,+6 -L/some/,/end/ -L9,29 I like it. It looks like paranoid script authors would have to check for paths like ‘--’ and ‘-L’ and quote them as ‘./--’ and ‘./-L’, a small price to pay for a nice syntax. Unfortunately, this is completely incompatible with the existing blame option syntax. i.e., existing scripts might do things like this: git blame -L1,8 -C or git blame -L1,8 Maybe there should be a line range required before every file specifier in this syntax, to avoid trouble. Borrowing syntax from sed, this makes git log -L1,8 -L45,+6 -L/some/,/end/ -L9,29 -L1,$ which is also a little clearer to look at, I think. > 'git log -L1,8 -- -L1,8' . This provides a single line range specifier for all files? Sounds convenient. # who wrote the opening comments? git blame -L '/^[/][*]/,/^ [*][/]/' -- '*.c' Summing up, with my refinement above, a human would parse args like this: When an -L option is encountered, remember the current state. Try to parse the remaining arguments as ((-L range)* filespec)*, where filespec has some appropriately strict meaning that forbids ‘-L’ and ‘--’. If that succeeds, we’re done. Otherwise, rewind. Look for an upcoming ‘--’. If -- is found, any -L arguments before the -- apply to all files specified. Unclaimed arguments before the -- are revision specifiers. If no -- is found either, any -L arguments before the first unclaimed argument that is not unambiguously a revision apply to all files specified. Arguments from that point on must be unambiguously paths. A little hairy. Maybe you can do better, but already it seems okay. Maybe the last case ought to disallow multiple -L arguments and multiple files, to encourage people to use the first syntax or an explicit ‘--’. Hope that helps, Jonathan