Linus Torvalds <torvalds@xxxxxxxx> writes: > On Sun, 7 May 2006, Pavel Roskin wrote: >> >> I'm only concerned that we would be hardcoding the word "branch". We >> could need fancy section names for other things in the future. > > Fair enough. We could have used some fake section name that you can't > generate any other way (in fact, "Branch.$branchname" would be that), but > the upside of using "branch" is exactly that you _can_ generate it with > the old-style syntax that is acceptable to older git versions too. Sorry, I do not follow the old-style syntax part. How about keeping the default syntax as it is (tokens are case insensitive and alnums only, dot separates tokens into sections), and when a token that violates that rule needs to be spelled out, require quoting, so: branch.foo BranCh.FoO branch.FOO are the same (section "branch.foo"), and if I have js/fmt.patch branch, I need to spell the configuration for that branch like so: branch."js/fmt.patch" or "branch.js/fmt.patch" and the URL variable for that section is $ git repo-config '"branch.js/fmt.patch".url' (BTW, you could even have a variable with dots in it by quoting the variable name, like "branch.js/fmt.patch"."fetch.option"; I do not know if it is worth it). My repository is full of topic branches that are named xx/yyyy. It is very handy to be able to say "show-branch --topics master 'heads/??/*' next" which would not show my other branches like "test", "throwaway", "rework", "temp", etc. - : 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