On Fri, Feb 06, 2015 at 12:14:35PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > This is highlighting the problem with "pager.*" that Junio mentioned > > recently, which is that the keyname has arbitrary data,... > > Yes, even if it is not "arbitrary" (imagine we limit ourselves to > the official set of commands we know about), the naming rule for the > "git" subcommand names should not be dictated by the naming rule for > the configuration variables, as they are unrelated. > > 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. A list of enum-like values where we are OK confining the names to the alnums is OK to use as an unbounded set of key values. Just like we have color.branch.*, we just pick a name within that syntax for any new values we add (and that is not even a burden; alnum names are what we would have picked anyway). -Peff -- 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