Junio C Hamano [off-list ref] 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.