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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 30, 2013, 17:09 UTC
Message-ID: <xmqqiowed6t3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <87bo27i85i.fsf@linux-k42r.v.cablecom.net>

Thomas Rast <tr@thomasrast.ch> writes:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <tr@thomasrast.ch> writes:
>>
>>> 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?