Re: Multiple line ranges and files in line level history browser

Hi,

Bo Yang wrote:

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 <file>

or

  git blame -L1,8 <rev> <file>

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 <rev> -L1,8 -L45,+6 <file1> -L/some/,/end/ -L9,29 <file2> -L1,$ <file3>

which is also a little clearer to look at, I think.

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