On Sun, Apr 18, 2021 at 01:39:31AM -0400, Jeff King wrote: > On Sat, Apr 17, 2021 at 02:37:39PM -0700, Junio C Hamano wrote: > > > Jeff King writes: > > > > > On Fri, Apr 16, 2021 at 11:14:51PM +0200, SZEDER Gábor wrote: > > > > > >> > @@ -1883,6 +1880,7 @@ static int do_git_config_sequence(const struct config_options *opts, > > >> > config_fn_t fn, void *data) > > >> > { > > >> > int ret = 0; > > >> > + char *system_config = git_system_config(); > > >> > char *xdg_config = xdg_config_home("config"); > > >> > char *user_config = expand_user_path("~/.gitconfig", 0); > > >> > char *repo_config; > > >> > @@ -1896,11 +1894,10 @@ static int do_git_config_sequence(const struct config_options *opts, > > >> > repo_config = NULL; > > >> > > > >> > current_parsing_scope = CONFIG_SCOPE_SYSTEM; > > >> > - if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, > > >> > > >> Removing git_config_system() from the condition breaks > > >> GIT_CONFIG_NOSYSTEM: > > > > > > Good catch. My gut feeling is that the new git_system_config() should > > > check NOSYSTEM and return NULL if it's set, and then we can get rid of > > > git_config_system() entirely. > > > > NULL -> /dev/null I guess? > > I was thinking NULL to catch this line from the post-image of Patrick's > series: > > if (system_config && !access_or_die(system_config, R_OK, > opts->system_gently ? > ACCESS_EACCES_OK : 0)) > ret += git_config_from_file(fn, system_config, data); > > which would see that we have no file at all. But that may be unexpected > for other callers (right now git_etc_gitconfig() can never return NULL, > and I'm not sure what would happen with "git config --system"; I suspect > it would do the regular config sequence instead, which is wrong). > > So yeah, probably returning /dev/null is more sensible (and makes it a > true alias for GIT_CONFIG_SYSTEM=/dev/null). > > -Peff It's only by accident that I dropped the call to `git_config_system()`, must've happened when resolving conflicts somewhere. The issue with just returning `/dev/null` from `git_system_config()` is that git-config(1) would be broken, as you hint at. We do not honor GIT_CONFIG_NOSYSTEM there if the "--system" flag was given. So yes, we could change it to return `/dev/null`, but that would change semantics of GIT_CONFIG_NOSYSTEM. I'm not sure doing this in the same series is a good idea. Even more so because with returning `/dev/null`, the conversion would be silent: whereas previous versions simply wrote to or read from the system-level config, we now pretend to have read or written something even though we didn't. Patrick