Re: Implementing branch attributes in git config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 9 May 2006, Johannes Schindelin wrote:
> 
> Okay, to summarize what people proposed (and that I remember):
> 
> 1) [branch."AnY+String"]

If we really change the syntax, I would oppose the ".". I realize I may 
have used it myself, and I think it would be good _internally_, but I 
think the syntax would be

	[branch "Any+String"]

which looks a lot more readable. Ie just a space (or, perhaps, "any 
combination of spaces and tabs").

> 4) [branch.just/allow-slashes/and-dashes]

Same here. If we break old parsers anyway, the "." has no redeeming 
value. You'd use it when _scripting_ stuff, but not anywhere else.

So in both cases, the above would turn into the _variable_ called 
"branch.Any+String/and-dashes.<key>" internally, and things that used "git 
repo-config" would say it that way, but the config file format should be 
human-readable.

We already do that human-readability thing. We say

	[core]
		name = Linus  Torvalds
		email = random

but we turn it internally into

	core.name  ->	"Linus Torvalds"
	core.email ->	"random"

and that's also the format you use for "git repo-config". Similarly, 
having

	[branch "master"]
		remote = git://....

in the config file should - for exactly the same reasons - be turned 
_internally_ into the association

	branch.master.remote    ->    git://...

and for exactly the same reason you'd just use

	git repo-config set branch.master.remote "git://..."

on the command line.

IOW, we _already_ do not match the internal and command line with the 
actal human-readable syntax.

			Linus
-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]