Re: Implementing branch attributes in git config

[Pavel Roskin <proski@gnu.org>]

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.

-- 
Regards,
Pavel Roskin