Re: [PATCH v2 6/7] Documentation: put blame/log -L in sticked form

Thomas Rast [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Thomas Rast [off-list ref] writes:

quoted

The next patch will document gitk -L, but gitk does not understand the
separated form ('gitk -L :foo:bar' results in an error).  Spell
git-blame and git-log -L, which are supposed to be "the same" option,
without the spaces to prevent confusion.

I agree that this patch may reduce confusion locally, but if we were
to go in this direction, we should be consistent and enforce "stuck"
form everywhere, not just the options you happened to have passed
thru to gitk, but other options such as "-S <revs-file>", and also
other commands that do not have anything to do with gitk (e.g. "git
commit -C<commit>", not "git commit -C <commit>".  Otherwise you
will give a wrong impression to readers as if they have to remember
which ones need to use the stuck form and which ones do not.

Hmm.  Do you want to go there?

Absolutely not ;-)

But that unpleasant place would be the logical conclusion where this
patch leads us to, I would have to say. I was hoping that there is
an alternative solution to avoid that.

For example, gitk's parseviewargs is very well aware of the options
it supports, and it goes through the argument list one by one,
acting on what option it is looking at. Couldn't it be extended to
handle options with stuck and unstuck form?  After all, it has to
know that "-L" and "-S" are supported options; it wouldn't be too
much to ask for the parser to also know that "-L" eats the next
token (i.e. pass the pair <"-L", next token> intact as two separate
args to the underlying "log") while it can pass "-L?*" as is, no?