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

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Nov 23, 2005, 15:39 UTC
Message-ID: <200511231639.59866.Josef.Weidendorfer@gmx.de>
In-Reply-To: <Pine.LNX.4.63.0511231549320.8191@wbgn013.biozentrum.uni-wuerzburg.de>

On Wednesday 23 November 2005 15:53, Johannes Schindelin wrote:

Show 8 quoted lines

> 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

Show 12 quoted lines

> (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
> 
>