Linus Torvalds <torvalds@xxxxxxxx> writes:
>> [branch]
>> name = linus
>> url = git://git.kernel.org/../torvalds/linux-2.6
>>
>> [branch]
>> url = git://git.kernel.org/../jgarzik/libata-dev
>> name = libata
>
> Yes, that would be a silent and confusing error.
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
-
: 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