Re: Get rid of .git/branches/ and .git/remotes/?

On Sun, 20 Nov 2005, Johannes Schindelin wrote:

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

----