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

quoted text
> 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.

?

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

quoted text
> 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.

quoted text
> 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 '='.

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