Stefan Beller <[email protected]> writes: > diff --git a/builtin/fetch.c b/builtin/fetch.c > index 4ef7a08afc..510ef1c9de 100644 > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -1344,7 +1344,7 @@ int cmd_fetch(int argc, const char **argv, const char > *prefix) > set_config_fetch_recurse_submodules(arg); > } > gitmodules_config(); > - git_config(submodule_config, NULL); > + load_submodule_config(); > } > > ... > +static enum { > + SUBMODULE_CONFIG_NOT_READ = 0, > + SUBMODULE_CONFIG_NO_CONFIG, > + SUBMODULE_CONFIG_EXISTS, > +} submodule_config_reading; > + > /* > * The following flag is set if the .gitmodules file is unmerged. We then > * disable recursion for all submodules where .git/config doesn't have a > @@ -83,6 +89,62 @@ int update_path_in_gitmodules(const char *oldpath, const > char *newpath) > return 0; > } > > +static int submodule_config(const char *var, const char *value, void *cb) > +{ > + if (!strcmp(var, "submodule.fetchjobs")) { > +... > + } > + return 0; > +} > + > +void load_submodule_config(void) > +{ > + submodule_config_reading = SUBMODULE_CONFIG_NO_CONFIG; > + git_config(submodule_config, NULL); > +}
OK, so anybody who does the git_config(submodule_config) must instead call this one, so that we can notice there is some "submodule" stuff configured. And that is ensured by making submodule_config private to this module. Nicely done. On a possibly related tangent, I've often found it somewhat irritating that that these two calls have to go hand-in-hand. > gitmodules_config(); > - git_config(submodule_config, NULL); I wonder if it makes sense to roll that gitmodule_config() thing into this function as well? Or do some callsites of load_submodule_config() need to omit call to gitmodules_config()? If so please disregard. Thanks.
