Thomas Rast <tr@xxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Thomas Rast <tr@xxxxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html