Re: [PATCH v3 05/13] parse the -L options

Bo Yang <struggleyb.nku@gmail.com> writes:

That itself smells like a bad design, unless done very carefully and documented clearly.

For example, what does this mean?

    $ git log -L n1,m1 master

As -L wants to see at least one path before running out of the command line argument, we take "master" as the filename. Hence, the command line does not have any revision specified and defaults to HEAD. I.e. "traverse from the current HEAD and show only commits that touch the line region n1,m1 that appears in the version of path 'master' in HEAD".

What about this?

    $ git log -L n1,m1 master..next one two

Clearly the user wants to traverse revision range between master and next. The -L option wants to see one path so slurps "one". The traversal however is further limited by a pathspec "two". Should the use of "one" as an argument to -L automatically add it also to the pathspec? I.e. "traverse from 'next' down to 'master', checking commits that touch either path 'one' or 'two', and show only commits that touch the line region n1,m1 that appears in the version of path 'one' in 'next'"?

Or perhaps master..next is the name of the file the user is interested in? I.e. "Starting from branches 'one' and 'two', show only commits that touch the line region n1,m1 that appears in file 'master..next'"? But that is a broken interpretation, as "-L range path" cannto possibly make sense if you have more than one starting point, and this interpretation gives you two (i.e. 'one' and 'two').

How would you disambiguate -Lpaths, revisions and pathspecs? How does -Lpath interact with pathspecs?

What if the name of the file the user wants to annotate begins with a "-"? For pathspec limiter, the users have already learned that "--" can be used to say "everything that comes after this token is pathspec", but that knowledge cannot be reused with this syntax.

It almost feels as if you want to have something more like

    -L <begin>,<end>[,<path>]

where <path> is mandatory for the first use of -L (i.e. missing ,<path> means the same path from the previous -L that has one) to make it clear that this is completely different from the normal pathspec.