On Tue, 9 May 2006 01:44:31 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> 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
-
: 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