Re: Implementing branch attributes in git config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]