From torvalds@osdl.org Sun Nov 20 20:10:10 2005 Date: Sun, 20 Nov 2005 10:09:50 -0800 (PST) From: Linus Torvalds To: Johannes Schindelin Cc: git@vger.kernel.org Message-ID: Subject: Re: Get rid of .git/branches/ and .git/remotes/? On Sun, 20 Nov 2005, Johannes Schindelin wrote: > > I just had a crazy idea. Since we have a framework in place to read/write > .git/config, I thought that maybe it would be a nice thing to move the > information which is in .git/branches or .git/remotes into the config. I considered it, but thee thing is, it really wants "nested names", ie having multi-level base-names for the variables. At the same time, I absolutely _abhor_ horrible crap like XML, which make nesting a fundamental part of their structure. XML may be "logical", but it has absolutely zero to do with being human-readable and clean. In short, XML is total and absolute CRAP (in fact, the "X" in "XML" stands for "Crap", but the XML designers were also incredibly bad spellers). So while the basic notion of the git ini file does support nesting (we could just make variable names be "base.level1.final" or any number of levels deep), I don't know what a sane format would be. I have one suggestion that in my opinion "fits" the .ini file syntax (see below), but people may well hate it. Basically I've considered saying that one or more '.' characters at the start of a section name would mean "re-use the previous one", so we could have (this is a really bad example, just to show the implications): [core] [.values] fixed = true nested = fine [..example] test = Hell yes [.other] example = strange [.] name = hi [section] example = yet another and that would result in a parse of core.values.fixed = true core.values.nested = fine core.values.example.test = Hell yes core.other.example = strange core.name = hi secontion.example = yet another and that seems reasonably clean. I'd also allow explicit multi-level section names: [core.values] fixed = true so you could always write the above config file in an alternate format: [core.values] fixed = true [core.values] nested = fine [core.values.example] test = Hell yes [core.other] example = strange [core] name = hi [section] example = yet another instead, using no implicit nesting at all (or, indeed, even re-using sections like "core.values"). That would allow things like [branches] [.origin] url = master.kernel.org:/pub/scm/git/git.git pull = master:origin [.mine] url = my.domain.com:/other/repo pull = master:mine (which could also be written as [branches.origin] url = master.kernel.org:/pub/scm/git/git.git pull = master:origin [branches.mine] url = my.domain.com:/other/repo pull = master:mine and the following mixed-indentation usage would be technically correct, but perhaps crazy: [branches.origin] url = master.kernel.org:/pub/scm/git/git.git pull = master:origin [.mine] url = my.domain.com:/other/repo pull = master:mine Basically, right now we only allow alphanumeric characters in the base name, and a new section name completely clears the old one. The above would be a very simple extension of that: we would allow '.' in addition to alphanumerics, and any initial '.' characters would _keep_ that many levels of the old name. I dunno. That seems a nice extension, and it would make these things very unambiguous. But how do other .ini-file-like things do this? And I'm not 100% convinced that putting these branches in the config file has any real advantages over keeping them as separate files. Having everything in one place is nice, of course, and being able to copy just one file around might be convenient, but it _does_ make the config file more complicated. Anyway, if you want to play with this, here's a trivial patch that may or may not work. Linus ---- diff --git a/config.c b/config.c index 915bb97..3b9f300 100644 --- a/config.c +++ b/config.c @@ -136,6 +136,19 @@ static int get_base_var(char *name) return -1; if (c == ']') return baselen; + if (c == '.') { + if (!baselen || name[baselen-1] == '.') { + for (;;) { + if (!name[baselen]) + return -1; + if (name[baselen++] == '.') + break; + } + continue; + } + name[baselen++] = c; + continue; + } if (!isalnum(c)) return -1; if (baselen > MAXNAME / 2) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html