Re: [RFC] Git config file reader in Perl (WIP)

["Nikolai Weibull" <now@bitwi.se>]

On 1/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> On Tue, 16 Jan 2007, Nikolai Weibull wrote:
>
> > And, as Johannes already pointed out, it's very disturbing having to
> > dump a configuration file so that it is more easily read by other
> > programs.
>
> I never pointed out such a thing. The configuration file is meant to be
> user-friendly, as the inventor did not mean to have a program like
> git-repo-config.

Then what did you mean in your mail from Jan 16, 2007 12:12 PM:

  How silly would that be: we parse an easy-to-read format,
  munge the easy-to-handle internal data format into another "easy-to-read"
  format which is then parsed by a script language into an easy-to-handle
  internal data format? No. NO.

?

> > That would suggest that the ini-based format for git's configuration
> > file is suboptimal.

> Not at all. Again, git's configuration file is meant for human inspection.
> Therefore, an ini-style file is optimal.

It is suboptimal because it's hard for computers to inspect.  An
optimal format would be accessible by all, whether human, machine,
robot, android, what have you.

I really don't like that people take my statements and somehow contort
them into meaning something else.  You can't take my statement and
then claim that because git's configuration file was meant for human
inspection my /suggestion/ about it being suboptimal is somehow flawed
because I didn't consider the original intent of the file in question.

Agreed, ini-style files are sweet for humans, but that's not what I
was saying.  My claim was that ini-style files aren't necessarily
optimal for parsing by computers.  I think that was made clear.  Also,
I only /suggested/ that it may be /suboptimal/ not that it in fact
/is/ suboptimal.

> And for scripts, we do have git-repo-config. But now some people want to
> be clever and read the whole config file in, to make it easier to have
> gazillions of configuration options for their script.

I maintain the git completion-definition for Zsh.  Being able to get
at the configuration settings is important, both for the completion of
git-repo-config, but also to provide completions of remote
repositories.  'git-repo-config -l' works fine, but it's not
guaranteed to be unambiguous, as the name of a remote repository can
contain characters like '=', so it can be difficult to decide where to
split the name of the remote repository from the url it represents as
the url can also contain '='.

> I was not happy when we introduced more relaxed section titles, and I am
> not happy now that I see what problems we introduced with that.

I'm with you on this one.

  nikolai