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

Re: [PATCH 1/2] parse-options: Add support for dumping out long options

From
Stephen Boyd <bebarino@gmail.com>
Date
Apr 12, 2012, 07:42 UTC
Message-ID
<4F86877A.9020703@gmail.com>
In-Reply-To
<CAMP44s37wm2G0vSmtND83ghrjHHfbyCbsKEoaUew-YxE73T=6A@mail.gmail.com>
On 04/11/2012 03:51 AM, Felipe Contreras wrote:
Show 8 quoted lines
> On Wed, Apr 11, 2012 at 1:29 PM, Stephen Boyd <bebarino@gmail.com> wrote:
>> The bash completion script wants to know what the long options are for a
>> certain command at runtime. Add a magical long option that nobody could
>> possibly ever use (--dump-raw-long-options) to get this information.
> 
> I thought about doing this, but I would like more than just dumping
> the options. In zsh one can show more than just the options; each
> option can have a description.

Cool. I don't use zsh but it sounds interesting. Perhaps the magical long option should grow an optional argument? i.e.

	--dump-raw-long-option=zsh
which would dump the options in a format that zsh would like?

Alternatively, we can make a tiny option description grammar that's easily parsed. I probably won't have time for this any time soon though.

Show 6 quoted lines
> 
> I was thinking on something like 'git help --raw'. We also need
> something like that to list all the plumbing commands, and options for
> certain options, like merge strategies, and so on. Perhaps it would
> even make sense to have a new 'git raw-help' command.
>

I'd like to avoid tying the long option stuff to git help so that other users of parse-options besides git (perhaps perf?) get the dumping support for free. Actually it works well for 'git notes <subcommand>' right now so it probably has to stay tied to each git command. Plus I think we've covered merge strategies and command lists already so I don't know how useful 'git help --raw' would be.

I have been pondering ways to get all the possible config keys dynamically. That would remove a huge list (~2000 lines) in the completion script that always needs updating. Doing that would probably require some sort of grep over all the source files and a special key comparison function to look for (#define CONFIG_MATCH strcmp might work). Even then I don't know how we would handle color.branch.* and similar things. Maybe we would just do those by hand.

Previous: Felipe ContrerasNext: Jonathan Nieder
Message 4 of 14 in “Dynamic long options for bash completion”
  1. 0/2 Dynamic long options for bash completionStephen Boyd, Apr 11, 2012
  2. 1/2 parse-options: Add support for dumping out long optionsStephen Boyd, Apr 11, 2012
  3. Felipe ContrerasApr 11, 2012
  4. Stephen BoydApr 12, 2012
  5. Jonathan NiederApr 11, 2012
  6. Stephen BoydApr 12, 2012
  7. SZEDER GáborApr 11, 2012
  8. Stephen BoydApr 12, 2012
  9. SZEDER GáborApr 15, 2012
  10. Junio C HamanoApr 15, 2012
  11. 2/2 completion: Use parse-options raw output for simple long optionsStephen Boyd, Apr 11, 2012
  12. Jonathan NiederApr 11, 2012
  13. SZEDER GáborApr 11, 2012
  14. SZEDER GáborApr 17, 2012

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.