Re: [PATCH 2/6] repo-settings: add submodule_propagate_branches

> From: Glen Choo <chooglen@google.com>
> 
> When processes recurse into submodules, the child processes have to
> use the same value of "submodule.propagateBranches" as the parent
> process regardless of whether the process is spawned in the superproject
> or submodule, otherwise the behavior may be inconsistent if the
> repositories don't agree on the config.
> 
> We haven't needed a way to propagate the config because because the only

> command that reads "submodule.propagateBranches" is "git branch", which
> only has one mode of operation with "--recurse-submodules". However, a
> future commit will teach "submodule.propagateBranches" to "git submodule
> update", making this necessary.
> 
> Propagate "submodule.propagateBranches" to child processes by adding a
> corresponding GIT_INTERNAL_* environment variable and repository
> setting, and setting the environment variable inside
> prepare_submodule_repo_env(). Then, refactor builtin/branch.c to read
> the repository setting.
> 
> Using an internal environment variable is a potentially leaky
> abstraction because environment variables can come from sources besides
> the parent process. A more robust solution would be to teach Git that
> the repository is a submodule and to only read
> "submodule.propagateBranches" from the superproject config. There is WIP
> for this on the ML [1].
> 
> Another alternative would be to pass "-c submodule.propagateBranches" to
> all child processes. This is error-prone because many different
> processes are invoked directly or indirectly by "git submodule update"
> (e.g. "git submodule--helper clone", "git clone", "git checkout"). With
> an environment variable, we can avoid this work because
> prepare_submodule_repo_env() is already called for submodule child
> processes.