Re: Implementing branch attributes in git config

From: sean <seanlkml@sympatico.ca>
Date: May 8, 2006, 23:30 UTC
Message-ID: <BAYC1-PASMTP0453E2D70B10C6D116167EAEA80@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.64.0605081905240.6713@iabervon.org>

On Mon, 8 May 2006 19:20:17 -0400 (EDT) Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 22 quoted lines

> You could tell people always to use:
> 
>  [branch."name"]
> 
> even if the branch name is all lowercase anyway. They could even use:
> 
>  [Branch."MyMixedCaseBranch"]
> 
> Then when you refer to something case-sensitive with the possibility of 
> funny characters, you put it in quotes, regardless of what it is.
> 
> For that matter, we could retain the quotes when we parse the file, and 
> reject [branch.master] for lacking the quotes, so that people who are only 
> exposed to branch names all in lowercase letters don't get habits that 
> will fail when they have a v2.6.16.x branch.
> 
> I don't think that people are likely to use older versions of git on the 
> same repository they've used newer versions on. (Clones of it, sure, but 
> that doesn't matter here.) But we should, in any case, make the code 
> ignore sections or lines with syntax errors, under the assumption that 
> they're a later extension and possibly legal but not anything the code 
> could be interested in getting from a parser that doesn't support them.

Unfortunately that's not the only place where you have to use the excessive quoting; you also have to do the same when using the git repo-config command line. All because we're clinging to case insensitivity and a very restrictive set of characters for identifiers in the config file. And just why are we clinging?

Believe when Linus offered the code originally he said that it was easier to start out very restrictive and loosen up later than it was to start loose and become restrictive later. That makes a lot of sense, but somewhere along the way we seem to have made a virtue out of something that is actually getting in the way of natural syntactic usage. There's no good reason for git to break with traditional and common practice in this case.

Sean