Re: [PATCH 1/1] config: allow user to know scope of config options

From: Jeff King <peff@peff.net>
Date: Dec 19, 2019, 05:05 UTC
Message-ID: <20191219050545.GC89333@coredump.intra.peff.net>
In-Reply-To: <xmqqa77pe7sx.fsf@gitster-ct.c.googlers.com>

On Wed, Dec 18, 2019 at 11:46:06AM -0800, Junio C Hamano wrote:

Show 11 quoted lines

> It almost makes me point fingers at config.c::config_with_options()
> where config_source is inspected and git_config_from_*() helpers are
> called without setting the current_parsing_scope.  Unlike these
> cases, when do_git_config_sequence() is called from that function,
> the scope is recorded in the variable before each standard config
> source file is opened and read.  What would we be breaking if we
> taught the function to set the current_parsing_scope variable
> correctly even when reading from the config_source?  That would
> certainly simplify this function quite a lot, but if the other parts
> of the codebase relies on the current behaviour, we cannot make such
> a change lightly.

As the author of the SCOPE enum, I think this is the right direction. The only users of current_config_scope() are in config callbacks (e.g., upload_pack_config() checks it for the "packobjectshook"), which you couldn't trigger via "git config" anyway.

The main reason I didn't set the scope before in config_with_options() is that it's not given the scope at all; git-config resolves it to the filename. So if git_config_source grows an enum to select the type, and all that filename-resolution gets pushed down into config_with_options(), the whole thing would fall out naturally, I think.

-Peff