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

Re: BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 6, 2015, 22:17 UTC
Message-ID
<xmqqr3u2d6ru.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20150206203716.GA10857@peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
>> That is one of the reasons why I had the "unbounded set, including
>> the ones under our control such as subcommand names" in the draft
>> update for the guideline.  I dropped that part after the discussion
>> to keep other "obviously agreed" parts moving, but we may have to
>> revisit it later.
>
> I think this may be the heart of where we were disagreeing. I took
> "unbounded set" to mean "a set where you might keep adding things
> forever". So fsck errors would count in that. But if you mean it as "a
> set where the syntax may be unbounded", then yeah, we definitely would
> not want it in the key name, as that becomes an unnecessary restriction.

What I mean is "possible keys are unbounded and its syntax is not under control of the 'config' subsystem". The syntax does not have to be unbounded; as long as it is wrong for the config subsystem to dictate what shape the possible values may take, it shouldn't be used as the top or the bottom level in the variable namespace where it has its own syntax restriction that may or may not match the requirement of the using code of the config subsystem.

Those who name Git subcommands will be limited to sane looking subcommand names that do not have SP in it, for example, but just because config subsystem does not want to see "_" in its keys, it should not force its world view to those who name subcommands.

If the names are not "unbounded", it becomes easier to live with such a third-party limitation (imposed by config subsystem), but otherwise, "we just pick a name within that syntax" becomes an unnecessary and artificial limitation.

Previous: Jeff KingNext: Junio C Hamano
Message 14 of 16 in “BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'”
  1. Andreas KreyFeb 6, 2015
  2. Jeff KingFeb 6, 2015
  3. Junio C HamanoFeb 6, 2015
  4. Jeff KingFeb 6, 2015
  5. config: add show_err flag to git_config_parse_key()Tanay Abhra, Feb 10, 2015
  6. Jeff KingFeb 11, 2015
  7. Junio C HamanoFeb 11, 2015
  8. add a flag to supress errors in git_config_parse_key()Tanay Abhra, Feb 16, 2015
  9. Jeff KingFeb 18, 2015
  10. Mikael MagnussonFeb 7, 2015
  11. Jeff KingFeb 7, 2015
  12. Junio C HamanoFeb 6, 2015
  13. Jeff KingFeb 6, 2015
  14. Junio C HamanoFeb 6, 2015
  15. Junio C HamanoFeb 6, 2015
  16. Jeff KingFeb 7, 2015

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.