list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Ryan Zoeller <>
Subject: Re: [RFC PATCH 1/2] parse-options: add --git-completion-helper-all
Date: Wed, 19 Aug 2020 14:05:52 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Ryan Zoeller's message of "Wed, 19 Aug 2020 20:51:11 +0000")

Ryan Zoeller <> writes:

> On 8/19/20 2:39 PM, Junio C Hamano wrote:
>> Ryan Zoeller <> writes:
>>> --git-completion-helper excludes hidden options, such as --allow-empty
>>> for git commit. This is typically helpful, but occasionally we want
>>> auto-completion for obscure flags.
>> Hits from "git grep -B2 OPT_NOCOMPLETE" tells me that these are
>> mostly unsafe options.  Those who accept the risk by saying
>> "complete all" should be allowed to see them.
>> The same with OPT_HIDDEN (including OPT_HIDDEN_<TYPE>) gives us a
>> mixed bag.  Many are unsafe, some are uncommon and the rest are
>> discouraged, or old synonym to some other option that does get
>> completed.  I am not sure if letting them be completed is an overall
>> win or makes the output from "git cmd --<TAB><TAB>" too noisy.
> If options marked OPT_HIDDEN are considered too internal to
> meaningfully expose, I'm happy to hide them. I defaulted to
> "show everything", and backing off from that is easy enough.

I think with the current state of HIDDEN which is applied unevenly
and for different purposes, the only sensible thing to do for the
"complete-all" operation is to show them.  If we audit all uses of
hidden and allocate different bit for the reason why they are marked
to be hidden, it may become possible for "complete-all" to be more
intelligent about them (e.g. not showing old synonyms that exist
only for helping muscle memory, while showing others), but before
that, I do not think it makes sense to hide them all.

> You're not misreading it; I apparently neglected to test the completion
> for '--no-' options with '--git-completion-helper', only
> '--git-completion-helper-all'. I'll apply the same show_all logic
> to this function.

That makes sense.

> I'm inclined to be repetitive in order to keep
> '--git-completion-helper-all' intact, e.g. for grepping.

Good reasoning.


  reply	other threads:[~2020-08-19 21:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 17:50 [RFC PATCH 0/2] Support enabling bash completion of all options Ryan Zoeller
2020-08-19 17:51 ` [RFC PATCH 1/2] parse-options: add --git-completion-helper-all Ryan Zoeller
2020-08-19 19:39   ` Junio C Hamano
2020-08-19 20:51     ` Ryan Zoeller
2020-08-19 21:05       ` Junio C Hamano [this message]
2020-08-19 17:51 ` [RFC PATCH 2/2] completion: add GIT_COMPLETION_SHOW_ALL env var Ryan Zoeller
2020-08-19 23:06 ` [PATCH v2 0/2] Support enabling bash completion of all options Ryan Zoeller
2020-08-19 23:06 ` [PATCH v2 1/2] parse-options: add --git-completion-helper-all Ryan Zoeller
2020-08-19 23:06 ` [PATCH v2 2/2] completion: add GIT_COMPLETION_SHOW_ALL env var Ryan Zoeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [RFC PATCH 1/2] parse-options: add --git-completion-helper-all' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).