From: Junio C Hamano Date: Sat, 11 Feb 2006 04:43:21 GMT Subject: Re: Git 1.1.6.g4d44 make test FAILURE report Message-ID: <7vwtg2pkt2.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <7v1wyasfam.fsf@assigned-by-dhcp.cox.net> Junio C Hamano writes: > git-sh-setup one is easy to fix. We could say something equally > silly like this instead: BTW, the reason I initially did this one and git-pull with git-var was there was no way to extract values from the config file easily from the command line back then. git-repo-config was initially called git-config-set and was about setting values. IMHO the configuration mechanism, and git-var in particular, is quite broken, and nobody bothered to fix it. (1) git-var -l can show all defined variables in the config file, but you cannot ask about specific variable it does not know about. You have to use git-repo-config for that: $ git var -l | head -n 4 core.filemode=true core.gitproxy=none for kernel.org pull.twohead=resolve pull.octopus=octopus $ git var core.filemode ;# it does not know usage: git-var [-l | ] $ git repo-config core.filemode true (2) git-repo-config does not have a way to list all the configuration items like "git-var -l". (3) neither of these commands know list of all the possible configuration items, nor types of them, so core.filename can be spelled as "1" or "true" to mean the same thing to our C code, but repo-config faithfully returns how the value is literally spelled in the configuration file. The following two means the same thing to the C layer, so the calling script needs to further interpret the output from git-repo-config: $ git repo-config core.filemode ;# [core] filemode=1 1 $ git repo-config core.filemode ;# [core] filemode=true true (4) worse, boolean 'true' can be specified by just having the configuration item in the file, but repo-config dumps core on that: $ git repo-config core.filemode ;# [core] filemode segmentation fault Above problems are not the only problems with git-var and git-repo-config, but these are not entirely these programs' faults. They come from the way the configuration file mechanism works. To allow different classes of configuration items to be defined by commands that know about them, there is no central registry of all the supported configuration items in the code. For example, "diff.*" configuration items can be interpreted only by C level programs that call git_config(git_diff_config). With the current structure, it is very hard for these commands to sensibly list all the configuration values (e.g. lack of "[core] filemode" in the configuration file ought to mean that the executable bit is unreliable i.e. core.filemode=false, but they cannot report it), or report the values taking into account their types. I do not think they even attempt to do so.