Re: Git 1.1.6.g4d44 make test FAILURE report

Junio C Hamano <junkio@cox.net> writes:

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 | <variable>]
	$ 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.