On Wed, Dec 18, 2019 at 11:46:06AM -0800, Junio C Hamano wrote: > 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
