Re: Git 1.1.6.g4d44 make test FAILURE report

[Junio C Hamano <junkio@cox.net>]

Junio C Hamano <junkio@cox.net> 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 | <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.