Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Okay, to summarize what people proposed (and that I remember): > > 1) [branch."AnY+String"] > > 2) multiple [branch] > > 3) magic <space>+<quoted> > > 4) [branch.just/allow-slashes/and-dashes] > > 5) the " for " notation Thanks for a nice summary. > Now, for the ease of use: > > (1), (3) and (4) are in the same league of easiness (except maybe that you > have to keep in mind to extra-quote in shell scripts with (1) and (3)), > (2) is especially good for people with a database mindset, and (5) is > annoying as hell. One thing you might want to consider is variable types and default values (eh, that makes two). When Linus first introduced the config mechanism, he made it so that a loosely coupled set of programs can take the "Why should I care about other programs configuration" attitude, and actively encouraged to do so by allowing custom config parsers inherit from the default parser, like the way git_diff_config() falls back on git_default_config() when it does not recognize the variable. It is quite a good design for most uses, except that it made it inconvenient to implement things like "git-repo-config -l" and "git-var -l". The point of this design _is_ that they cannot know what the set of possible variables, their types and the default values when missing are, so by design the script that used "git-var -l | grep" to read the configuration needed to know that a boolean can be denoted by existence, value set to zero or non-zero integer, or string "true"/"false" (i.e. "filemode", "filemode=1", and "filemode = true" mean the same thing; BTW I think we would probably want to add "yes"/"no" here). Later it was made easier to use by Pasky with "repo-config --type" option. The caller supplies the name of the variable and the type and repo-config gets the value -- the caller knows what it wants to use, so having it to know what type of things it is interested in is not so bad, so the type problem was practically solved. But it still feels somewhat hacky. With (2) and (5), we have a bound set of "se.ct.ion.variable"; we could enumerate the variables we care about, define what they mean and what their types and default values are (we need to do that for Documentation/config.txt anyway). With many parts of the standalone git plumbing programs migrating into builtins, I think it is not a bad idea to have a central table of all the configuration variables that the core knows about. Porcelains and scripts could define customized tables that describe the sections/variables they also want to see and act on in the configuration file, and call git-repo-config with that table as an optional parameter. > Now, for the ease of implementation: > > (1) and (3) are in the same league, they have to change the way the config > is parsed as well as make downcasing conditional in repo-config. (2) is > obviously hardest of all. (4) is very easy (one line in config.c), and (5) > easiest (nothing to do). > > Now, for the versatility, i.e. what you can express with the syntax: >... > Obviously, I deem (4) the best solution ATM, because it has all the > expressability needed, while being the simplest. If we are shooting for "let's not do this again", I do not think (4) without some quoting convention is good enough. Today, we are talking about branch names so we could give them artificial limits, which could be weaker than what we already have on the branch names, but we would later regret that, when we start wanting to have other names in the configuration (e.g. people's names). - : 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