Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> It does make sense to move this to run-command.c from submodule.c >> and the function name is already suitable for being global. I >> however cannot help wondering if we should also pay attention to the >> GIT_CONFIG_KEY_$n and GIT_CONFIG_VALUE_$n pairs (which is not a new >> problem in this patch). > > Note that I changed the function name (the previous one was too > submodule-specific). Ah, sorry for a stale mention of that thing---in any case, the name is suitable for a global. > As for the config pairs, they are currently being > passed through - do you have a situation in mind in which they should > not be passed through? Wasn't the GIT_CONFIG_KEY/VALUE meant as a moral equivalent of the GIT_CONFIG_PARAMETERS for those scripts that do not want to bother following the quoting rules of the single parameter approach? I do not see why we should filter configuration variables passed via one mechanism and let variables passed via the other machanism through. That feels inconsistent (I suspect that there may already be inconsistencies introduced when GIT_CONFIG_KEY/VALUE mechanism was added, though).
