Junio C Hamano <gitster@xxxxxxxxx> writes: > My gut feeling is that this is merely a bug that we can fix without > worrying too much about users screaming at us complaining that they > relied on the current behaviour. Without --global we do read from > both, so with with "--global" the behaviour is inconsistent. So, here is what I think happens, if anybody wants to get their hands dirty. builtin/config.c::cmd_config() notices "--global", and tries to choose between user_config and xdg_config and picks one. The choice is stored in given_config_source.file Eventually, "--get", "--get-all", etc. are handled by calling builtin/config.c::get_value() and that function eventually calls config.c::config_with_options(). config.c::config_with_options(), when config_source.file exists, uses only that file. There is no facility to say "read from this one, and also that one". When the command is called without "--global", given_config_source.file is not set and in that case, config.c::config_with_options() does the "config sequence". This is implemented in config.c::do_git_config_sequence(). What is disturbing about this function is that it knows about two global configuration files, and finds out about these two files by calling the same git_global_config() helper function builtin/config.c::cmd_config() uses. However, the logic used to decide if the file(s) are actually attempted to be read (e.g. it is not a configuration error to lack ~/.gitconfig) is slightly different. Ideally, it would be very nice if the high level caller in cmd_config() loses the duplicated logic and instead just sets a single "we are dealing with --global" bit in given_config_source structure, and config_with_options() is taught to reuse the "we need to read both of them" logic in do_git_config_sequence() when the bit is set.
