Thread (115 messages) flat view 115 messages, 4 authors, 2018-12-11

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

From: Duy Nguyen <hidden>
Date: 2018-02-01 00:06:19

On Thu, Feb 1, 2018 at 4:04 AM, Eric Sunshine [off-list ref] wrote:
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.
It's not only for dangerous options (I forgot to mention this in the
commit message, I will in v3). The --continue|--abort|--skip should
only show up when you are in a middle of rebase/am/cherry-pick.
git-completion.bash handles this case separately and only put them in
the completion list  when appropriate. --git-completion-helper must
not include these or the trick done by git-completion.bash becomes
useless.
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).
Interesting. So we now have two classes of "no complete". One can't be
configurable (--continue|--abort|--skip) and one can. I'll use two
separate flags for these, though I'm not adding the configuration
option right now. It's easy to do and can way until someone actually
asks for it.
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help