>From Philippe Blain, Thu 05 Mar 2020 at 23:17:54 (-0500) : > In the commit title: s/apply/applies Oups, missed this one. > Initialized, active and populated, as far as I understand, are three different concepts. [...] > From what I understand of the code, git-fetch really recurses into *populated* submodules, > and does not consult the submodule.active or submodule.<name>.active config settings. > If you look at builtin/fetch.c::cmd_fetch, and the functions it calls, but is_submodule_active is not in the call chain. > I tested that setting submodule.<name>.active to false and calling > > git fetch --recurse-submodules=yes > > still fetches in the submodule(s). So this should stay as "populated". Thanks for the thorough review! I had tested that `git-pull` was only updating the worktree of active submodules, but missed that it was still fetching non active submodules. In light of this I think this is even more important to mention which command affects which submodules in the doc. > That's only partly correct: I tested setting submodule.<name>.active to false and doing > > git pull --recurse-submodules > > This does fetches the submodule but does not update its working tree, due to the call to > is_submodule_active in prepare_to_clone_next_submodule in builtin/submodule--helper.c I still left 'active submodule' here in order to not render the formulation too heavy. Since it is implicit that `pull` goes through fetch, I hope it is clear that the fetching still involves all populated submodules. -- Damien Robert http://www.normalesup.org/~robert/pro
