On Mon, Feb 5, 2018 at 5:46 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > On Wed, Jan 31 2018, Eric Sunshine jotted: > >> On Wed, Jan 31, 2018 at 6:05 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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. 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
