Re: Implementing branch attributes in git config

Linus Torvalds <torvalds@osdl.org> writes:

Although I haved raised objections, I actually started to like the idea of using multiple [branch] (or wasn't it [remote] given the example variables we have been using?) sections.

We should first depart from the Windoze .INI mindset. While I do not think users expect case insensisitivity, only because the section headers are marked with [brackets], if that syntax somehow makes people expect such, maybe we should stop using [bracket] as section markers.

Whatever marker we end up using, I'd suggest somewhat different approach.

 - Treat each part that are grouped under [bracketted-string]
   marker as a bag of variable=value pairs.  Loosely speaking,
   the bracketted-string defines a schema -- what kind of
   variables are expected to be there in that seciton.  For
   example, a section for things we traditionally had in remotes
   file would contain fields (variables) such as url, fetch, and
   push (we might add proxy to this list).  And we call this
   "bag of variable=value" a section.

 - There can be multiple sections in a config file that uses the
   same schema.  The example at the beginning of this message
   is perfectly valid.  It defines two sections of type
   [branch], each of which has two variables (name and url) in
   it.

Unlike your earlier suggestion, the second [branch] is not just for readability; it is mandatory, because we are talking about two different [branch]es (eh, that's [remote]s, really), it needs to be there to separate two instances.

The above would break the existing repo-config command, but let's forget about it for now. I think we are breaking forward/backward compatibility in any proposals brought up so far anyway.

We would need user interface level commands to

	add a new section
        delete a section

We would need a way to identify a secion, perhaps using a value of arbitrary key (e.g. "where name=blah"). Creating a section could be implicit, just like the current repo-config.

        add a variable=value to a section
        delete a variable=value from a section
	retrieve variables' values from a section
	list value of a variable from all sections of a kind.

Probably need to support the same variable name appearing more than once, just like the current multi-value support.

The current multi-value stuff assumes that multi-values are exceptions, and rare. While I do not necessarily agree with that, for now let's assume that is true.

Creating a new section with given variables:

	$ cfg --set section var value var value ...
   (eg) $ cfg --set branch name master merge origin pull linus

    Here, 'var' and 'value' are case sensitive; if they have
    syntactical metacharacters (WS, =, quotes, etc), they need
    to be quoted when cfg command writes to the file (i.e. the
    user do not have to quote more than necessary to protect
    them from the shell).

Updating an existing section's variables, or create a new one:

	$ cfg --replace section.var value where var0 = val0
   (eg) $ cfg --replace remote.url git://... where name = linus

    Look for a "remote" section that has a variable "name" with
    value "linus" in it, and replace its "url" variable with
    "git://...".  If there is no "remote" section with such a
    name, create it.  For the key matching syntax, I do not
    insist on using "where" (I merely used it for continuity
    from the previous discussion).  For the comparison operator,
    in addition to the '=' shown above, we would probably want
    to have regexp match (perhaps ':' to emulate "expr") as well.

Retrieving a variable:

	$ cfg --get section.var [where var0 = val0]
   (eg) $ cfg --get remote.url where name = linus

List sections:

	$ cfg --list section.var
   (eg) $ cfg --list remote.name

So, an equivalent of "grep -H URL: .git/remotes/*" becomes something like:

	for name in `cfg --list remote.name`
        do
             	url=`cfg --get remote.url where name = "$name"`
                echo "$name: URL: $url"
	done