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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> 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.