Re: Implementing branch attributes in git config

Hello!

I feel so bad that I sparked this discussion about config files and couldn't participate in it in real time. I'd like to summarize my thoughts on the subject - maybe they will help us come to an agreement.

User convenience trumps backward compatibility.

Case in-sensitivity is almost a foreign concept for POSIX. There is no expectation (except among newbies) that bash would run grep if it's asked to run Grep. Why would git-repo-config need to foster such expectations, and do so inconsistently, e.g. for key names but not for values?

The config files use escaping by backslash, which is easier to work with than quoting. Quoting should be introduced if backslash escaping doesn't work, and I think backslash escaping in fine.

Users who edit the config file manually and mindlessly get what they deserve. Users who misspell "master" as "Master" get what they deserve. Occasional typos could be caught and reported if practical, but hand holding shouldn't be a design goal.

Either we need the third layer in key hierarchy, and that layer should support user defined strings, or we need to relax one of the layers to user define strings. User defined means that it can include spaces, slashes, dots and many other characters. Whenever a character is not allowed, we should have a good reason.

An example of two-layer approach:

[branchdescriptions]
	master = My master branch
	netdev-master = Patches for netdev
[branchremotes]
	master = origin
	netdev-master = netdev

All other examples quoted here are examples of three-layer approach. Either the extra key is inserted into the section name (Linus) or into the value (Dscho). It can also be inserted into the existing key.

If we want to group all branch properties for each branch, we have to go three-layer. If we don't want that, the above example should accepted as the simplest approach.

Adding an additional key layer to the existing keys is syntactically nice, but buys us very little in terms of ability to group branch data:

[branchdata]
	remote[master] = origin
	remote[netdev-master] = master
	description[master] = My master branch
	description[netdev-master] = Patches for netdev

Adding an additional key layer to the value is inherently fragile. The value has free format, and so is the new key. It also has the same problem that the data for different branches is mixed together.

Adding an additional key layer to the section name looks strange syntactically, but it's the approach that gives us immediate grouping of all branch data for every branch.

My personal preference is the Linus' proposal, but with backslash escaping instead of quoting, with explicit "branch." in the section names, and with case sensitive sections and keys.