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

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 05 Feb 2018 11:46:20 +0100

On Wed, Jan 31 2018, Eric Sunshine jotted:

> On Wed, Jan 31, 2018 at 6:05 AM, Nguyễn Thái Ngọc Duy <[email-masked]> wrote:
>> 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.