Le 2022-08-29 à 16:54, Glen Choo via GitGitGadget a écrit : > From: Glen Choo <chooglen@xxxxxxxxxx> > > 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 "because because" > 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. I think this is a good justification. I agree adding '-c' everywhere would be error-prone.
