On Thu, May 18, 2017 at 12:00 PM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: > On 05/18, Stefan Beller wrote: >> >> +static enum { >> >> + SUBMODULE_CONFIG_NOT_READ = 0, >> >> + SUBMODULE_CONFIG_NO_CONFIG, >> >> + SUBMODULE_CONFIG_EXISTS, >> >> +} submodule_config_reading; >> > >> > Any way we can have this not be a global, but rather a parameter? You >> > could pass in a pointer to this value via the callback data parameter in >> > the submodule_config function. >> >> As said in the reply to Junio, this patch has been sitting on my hard drive >> for a while and was written before you started the attempt to de-globalize >> the state of git. >> >> Ideally this setting would be part of the repository object. For example >> the repository object would have a "submodule_config" pointer, initialized >> to NULL, which can then be set to the read config or a static empty_config >> if no such config exists. > > I'm not quite sure I agree, or rather we may be talking about two > different things or I'm misinterpreting the patches. From these patches > it seems like 'submodule_config' that you are refering to is not the > actual submodule configuration but rather some options that are stored > in .git/config or other various config locations (home, system, etc). You are reading the patch correctly. > What would need to be part of the repository object (and is in my WIP > that I'll hopefully send out so i can get some feedback) would be the > submodule_cache which is the internal representation of a repository's > .gitmodules files. and in the light of this patch, we'd want to have a cache the flag if the regular config contains any submodule related things, so for now a static seems to be the best option and once we have the repo object we'd have a bit from the flags section (assuming we'll have a flags section down the road): struct repo { .... struct regular_config *config_ptr; unsigned config_has_submodule_stuff : 1; unsigned config_loaded_submodule_config : 1; } Then the caching decision would be: static int submodule_config(const char *var, const char *value, void *cb) { struct repo *r = cb; if (!strcmp(var, "submodule.fetchjobs")) { r->config_has_submodule_stuff = 1; parallel_jobs = git_config_int(var, value); if (parallel_jobs < 0) die(_("negative values not allowed for submodule.fetchJobs")); return 0; } else if (starts_with(var, "submodule.")) { r->config_has_submodule_stuff = 1; return parse_submodule_config_option(var, value); } else if (!strcmp(var, "fetch.recursesubmodules")) { r->config_has_submodule_stuff = 1; config_fetch_recurse_submodules = parse_fetch_recurse_submodules_arg(var, value); return 0; } return 0; } void load_submodule_config(struct repo *r) { # assume r->config_has_submodule_stuff and config_loaded_submodule_config # was set to 0 on repo init if (r->config_loaded_submodule_config) return; git_config(submodule_config, r); r->config_loaded_submodule_config = 1; } That said, I agree that the >> >> +static enum { >> >> + SUBMODULE_CONFIG_NOT_READ = 0, >> >> + SUBMODULE_CONFIG_NO_CONFIG, >> >> + SUBMODULE_CONFIG_EXISTS, >> >> +} submodule_config_reading; with its global state is counterproductive for your series, but I see an easy integration path. As we do not have the repo struct, I proposed it this way to make submodule progress. Thanks, Stefan