git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 1/2] parse-options: add --git-completion-helper-all

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 19, 2020, 21:05 UTC
Message-ID
<xmqq5z9etkgf.fsf@gitster.c.googlers.com>
In-Reply-To
<a51ff9bb-47df-63ce-0b7f-508e064f4e3f@rtzoeller.com>
Ryan Zoeller <rtzoeller@rtzoeller.com> writes:
Show 21 quoted lines
> On 8/19/20 2:39 PM, Junio C Hamano wrote:
>> 
>> Ryan Zoeller <rtzoeller@rtzoeller.com> 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.
Thanks.
Previous: Ryan ZoellerNext: Ryan Zoeller
Message 5 of 9 in “Support enabling bash completion of all options”
  1. 0/2 Support enabling bash completion of all optionsRyan Zoeller, Aug 19, 2020
  2. 1/2 parse-options: add --git-completion-helper-allRyan Zoeller, Aug 19, 2020
  3. Junio C HamanoAug 19, 2020
  4. Ryan ZoellerAug 19, 2020
  5. Junio C HamanoAug 19, 2020
  6. 2/2 completion: add GIT_COMPLETION_SHOW_ALL env varRyan Zoeller, Aug 19, 2020
  7. 0/2 Support enabling bash completion of all optionsRyan Zoeller, Aug 19, 2020
  8. 1/2 parse-options: add --git-completion-helper-allRyan Zoeller, Aug 19, 2020
  9. 2/2 completion: add GIT_COMPLETION_SHOW_ALL env varRyan Zoeller, Aug 19, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.