Hi Glen & Philippe, Thanks for taking the time to look into this! > > I think the bigger question to ask is "what is the intended effect of > > 'submodule.recurse = true' and 'fetch.recurseSubmodules = false'?". > > Yes, I agree that it would be nice if Huang clarified that as I'm not sure > either of the use case. > > Perhaps this is just a performance optimization? i.e. after fetching in > > the superproject, the user wants to skip the rev walk that discovers new > > submodule commits. > > So the use case here is just performance optimization. My team has over 10 submodules and I do not deal with most of them. I want to be able to pull the latest changes quickly (fetching submodules adds ~13 seconds when there are no new commits to a pull that would otherwise take ~1 second). I want my working tree to be clean after pulls/checkouts. So checkouts and other commands that update my commit HEAD should still recursively update submodules (hence submodule.recurse is true). Although, I may be naively assuming that fetches can be avoided if I only care about the commit referenced in the submodule link. If that isn't the case, then the more practical use-case would be 'submodule.recurse = true' and 'fetch.recurseSubmodules = on-demand', so at least submodules are only fetched when there are changes. The other use-case here, which I should have probably included in my original report, is `git pull` currently also recurse into *inactive submodules*. i.e. submodules that are not set in "submodule.active". If my submodules are not active, and not initialized, then git should not fetch commits in those submodules regardless of the settings in fetch.recurseSubmodules I hope this helps clear up a few things! Thanks, Huang
