Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html