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).
