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

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

On Wednesday 23 November 2005 15:53, Johannes Schindelin wrote:
> Okay. What about this config file?
> 
> -- snip --
> 	[myporcelain.headproperties: my/head.name]
> 		merge.candidates = my/other.head
> 	[myporcelain.headproperties]
> 		merge.candidates = blabla for my/head.name
> -- snap --

I am not sure you want to show here. Your example gives

 myporcelain.headproperties.merge.candidates = my/other.head for my/head.name
 myporcelain.headproperties.merge.candidates = blabla for my/head.name

I.e. 2 values for the same variable with the same "for" specification.
This is perfectly valid.

Are you talking about the multiple representations for the same thing?
Then hierarchical config keys already introduce this:

 [myporcelain]
    headproperties.merge.candidates = blabla

is the same as

 [myprocelain.headproperties.merge]
    candidates = blabla
 
> I am not totally opposed to what you are trying, but I think it 
> contradicts the KISS principle.

This suggestion is about easier reading of config files; IMHO far easier
with some use cases; but yes, it is arguable if it's worth an added
complexity of config.c/config-set.c.

And of course this is no issue if config files are only to be written
by git-config-set. But I do not think this was the goal of the config
format.

Josef

> (Note: the restriction that key names must 
> not start with a digit is also a contradiction to that.)
> 
> Ciao,
> Dscho
> 
> -
> 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
> 
>