On 1/16/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - To unsubscribe from this list: 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