Hi, On Tue, 9 May 2006, Jakub Narebski wrote: > Linus Torvalds wrote: > > > I would suggest a much more readable format: > > > > [core] > > ... > > > > [branch "core"] > > ... > > > > [remote "core"] > > ... > > > > and yes, enforce the <space>+<quoted name> format. We'd turn it internally > > into some random internal string format (probably replacing the space with > > a dot, and removing the quotes, so it would become "remote.core.<key>"). > > I'm all for it. Nice compromise of [branch."miXedCaps"] and ["miXedCaps"], > human readable end editable, and easy parsable. 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 Of all these, only (5) is backwards compatible, but it is also the only one where you have to type the branch name over and over again. However, the old gits do not really know what to do with the [branch] section anyway, so you could consider (2) (and (4), if you do not have branch names with slashes and/or dashes) backwards-compatible, because git will continue to work -- ignoring the funny entries. (1) and (3) definitely would make an old git choke. 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. 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: The same for all (except for (4) which has very weak restrictions on the branch name). Oh, I completely forgot about another proposal: (6) subkeys (something like "url[branchname] = blablabla"). It has about the same effects as (1) or (3). Another thing: I completely ignored the case sensitivity. Because it is irrelevant. Why? Because you do not have two branches which are only different by case-ness. It is confusing, and that's why. And you don't need to handle the case specially, because the comparison is done by downcasing anyway. Obviously, I deem (4) the best solution ATM, because it has all the expressability needed, while being the simplest. Ciao, Dscho - : 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