Re: [PATCH v2] pull: only pass '--recurse-submodules' to subcommands

> From: Glen Choo <chooglen@google.com>
> 
> Fix a bug in "git pull" where `submodule.recurse` is preferred over
> `fetch.recurseSubmodules` when performing a fetch
> (Documentation/config/fetch.txt says that `fetch.recurseSubmodules`
> should be preferred.). Do this by passing the value of the
> "--recurse-submodules" CLI option to the underlying fetch, instead of
> passing a value that combines the CLI option and config variables.
> 
> In other words, this bug occurred because builtin/pull.c is conflating
> two similar-sounding, but different concepts:
> 
> - Whether "git pull" itself should care about submodules e.g. whether it
>   should update the submodule worktrees after performing a merge.
> - The value of "--recurse-submodules" to pass to the underlying "git
>   fetch".
> 
> Thus, when `submodule.recurse` is set, the underlying "git fetch" gets
> invoked with "--recurse-submodules[=value]", overriding the value of
> `fetch.recurseSubmodules`.
> 
> An alternative (and more obvious) approach to fix the bug would be to
> teach "git pull" to understand `fetch.recurseSubmodules`, but the
> proposed solution works better because:
> 
> - We don't maintain two identical config-parsing implementions in "git
>   pull" and "git fetch".
> - It works better with other commands invoked by "git pull" e.g. "git
>   merge" won't accidentally respect `fetch.recurseSubmodules`.
> 
> Reported-by: Huang Zou <huang.zou@schrodinger.com>
> Helped-by: Philippe Blain <levraiphilippeblain@gmail.com>
> Signed-off-by: Glen Choo <chooglen@google.com>
> ---
>     pull: only pass '--recurse-submodules' to subcommands
>     
>     Thanks for the debugging help :)
>     
>     Changes since v1:
>     
>      * add a test that actually tests the precedence of the config values
>        * I've kept the previous test; it has always worked, but it still
>          seems like a useful smoke test
>      * reworded the commit message slightly