Re: [PATCH v2 01/41] parse-options: support --git-completion-helper

On Mon, Feb 5, 2018 at 5:46 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

On Wed, Jan 31 2018, Eric Sunshine jotted:

quoted

On Wed, Jan 31, 2018 at 6:05 AM, Nguyễn Thái Ngọc Duy [off-list ref] wrote:

quoted

This option is designed to be used by git-completion.bash. For many
simple cases, what we do in there is usually

    __gitcomp "lots of completion options"

which has to be manually updated when a new user-visible option is
added. With support from parse-options, we can write

    __gitcomp "$(git command --git-completion-helper)"

and get that list directly from the parser for free. Dangerous/Unpopular
options could be hidden with the new "NOCOMPLETE" flag.

I wonder if this option should be named DANGEROUS rather than
NOCOMPLETE to better reflect its intention. The reason I ask is that
it is easy to imagine git-completion.bash some day growing a new
configuration option to allow people to complete these "dangerous"
options, as well, rather than us imposing, with no escape hatch, our
idea of what should and should not complete.

It's not uncommon for "bug reports" to be sent to the list stating
that such-and-such option (say, --force) does not autocomplete. Our
stock answer is "oh, that's a dangerous option, so you'll have to type
it manually". If git-completion.bash gains new configuration to allow
dangerous options, then our answer can become "oh, that's a dangerous
option, if you really want it to complete, then enable
GIT_COMPLETION_DANGEROUS" (or whatever).

I think we should just drop this idea of dangerous and complete things
like --force. On the same systems people use this on this will complete
--force:

    rm / --recurse --for<TAB>

So it's odd UI to be inconsistent with that. But if others disagree and
want to keep the current behavior I'd definitely turn the "complete
'dangerous'" option.

Personally I like completing all options too (and will be happier if
plumbing commands are completable; it seems much less work to do that
now). But I don't know git-completion.bash history and don't want to
revisit why some options are filtered out or the inconsistency.
-- 
Duy