Re: Bug Report: fetch.recurseSubmodules doesn't affect git pull as otherwise stated in the git config docs

[Huang Zou <huang.zou@schrodinger.com>]

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