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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Bo Yang wrote:

> git log <revision> -L1,8 -L45,+6 <file1> -L/some/,/end/ -L9,29 <file2> <file3>

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.

> 'git log -L1,8 <revision> -- -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