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

Jeff King [off-list ref] writes:

quoted

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.