Re: Implementing branch attributes in git config

From: sean <seanlkml@sympatico.ca>
Date: May 9, 2006, 02:47 UTC
Message-ID: <BAYC1-PASMTP04C9C4BF5B89E55B9D877AAEA90@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.64.0605081854190.3718@g5.osdl.org>

On Mon, 8 May 2006 18:57:08 -0700 (PDT) Linus Torvalds <torvalds@osdl.org> wrote:

Show 7 quoted lines

> Btw, I keep coming back to the same
> 
> 	["jc/show-branch-dense"]
> 		remote = git://...
> 
> branch specifier syntax. It just seems very intuitive and is easy to 
> parse.

We already need such section headers for remotes, and for branches.. both which may well need to be quoted as above.. how to distinguish between them? How to handle the next case that comes along where we want these special header semantics?

We really need:

   [branch.Whatever]

and:

   [remote.Whatever]

As in the case of "origin" where we have a remote and a branch named that.

> The only real downside ends up being the non-forwards-compatibility thing. 
> But trying to be forwards-compatible for old git versions with this thing 
> would seem to be a major pain for rather slim gain.

What's the advantage of section quotation marks over just allowing these characters in regular section names? To be specific, what is wrong with:

   [jc/show-branch-dense]
       remote = git://...

If we just relax the legal characters in identifiers to include slash and dash? It doesn't seem to be any different in amount of code needed to achieve, and it is just as intuitive (perhaps more so) and no worse on the forward-compatibility thing.

If we continue with case insensitive section names, it's quite possible for the user to mess up while hand editing or forgetting proper "git" quoting rules on the command line and end up with silent breakage:

$ git repo-config "Branch".url = git://...  
        (updates section ["Branch"])

And then the next time forget the quotes and use:

$ git repo-config Branch.url = git://...    
         (updates section [branch])

And all of a sudden the user is updating _different_ sections with unpredictable results. This is just awkward; why not just admit that section names should always be case sensitive if we're going to put filenames inside them?

Sean