Re: Implementing branch attributes in git config

From: sean <seanlkml@sympatico.ca>
Date: May 9, 2006, 00:08 UTC
Message-ID: <BAYC1-PASMTP03ADC2F3E75E482ADC5CD3AEA90@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.63.0605090142280.5778@wbgn013.biozentrum.uni-wuerzburg.de>

On Tue, 9 May 2006 01:44:31 +0200 (CEST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 10 quoted lines

> Hi,
> 
> On Mon, 8 May 2006, sean wrote:
> 
> > There's no good reason for git to break with traditional and common 
> > practice in this case.
> 
> It is well established common practice that ini files (and everything in 
> config resembles an ini file) have case insensitive section headers as 
> well as keys.

Not in ini files that support section headers that represent filenames and directories. Exactly because those things _are_ case sensitive and include more characters than just alnums. But we're not just talking about the config file syntax we're talking about how the user must ultimately refer to branches with uppercase character. Now everytime a person wants to add a branch attribute via repo-config they have to remember that git thinks uppercase characters should be quoted. Doesn't that sound ridiculous to you?

The point is that we should make the config file and the repo-config command easy for the _users_. Instead we're going to make them use some crazy extra syntax because we refuse to come to terms with the limitations of the choices we've made so far.

One option, which I don't really like and comes with its own set of problems, would be to do something like:

[branch1]
    streetname = "p4/BrAnCH"
[branch2]
    streetname = "origin"

And then allow reference to it from git-repo-config by either branch# or the value of street name. While it would take some extra coding but at least it lives within the current restrictions for key names.

It just seems that once you have to even consider options like this, a big red flag should be raised about some of the assumptions we've built into the system.

Sean