Am 16.11.2013 22:42, schrieb Thomas Rast: > Dmitry Neverov <dmitry.neverov@xxxxxxxxxxxxx> writes: > >> git -c core.askpass=pass.sh clone main-repo >> cd main-repo >> git submodule init >> git submodule sync >> git -c core.askpass=pass.sh submodule update >> >> The last command asks for a password interactively. >> >> I've run bisect, it seems like it started failing from commit >> be8779f7ac9a3be9aa783df008d59082f4054f67. I've checked: submodule update >> works fine in 1.8.5.rc2 with removed call to clear_local_git_env. > > Aside from GIT_CONFIG_PARAMETERS, which this needs ... Yes, if I understand GIT_CONFIG_PARAMETERS correctly we should not clean it as the user explicitly asked us to use that setting. > ..., I wonder if we > should also let other variables pass through. For example, if the user > went out of their way to set GIT_ALTERNATE_OBJECT_DIRECTORIES, shouldn't > we also respect that? Hmm, I'm not so sure. Does the user really want the setting of GIT_ALTERNATE_OBJECT_DIRECTORIES to be honored inside the submodule too or would he want a different setting (including none)? I suspect different users would give different answers. And wouldn't a working GIT_CONFIG_PARAMETERS (or configuring the submodule after the initial clone) be the solution for that? > The list of variables that is unset by clear_local_git_env is $(git > rev-parse --local-env-vars), currently > > GIT_ALTERNATE_OBJECT_DIRECTORIES > GIT_CONFIG > GIT_CONFIG_PARAMETERS > GIT_OBJECT_DIRECTORY > GIT_DIR > GIT_WORK_TREE > GIT_IMPLICIT_WORK_TREE > GIT_GRAFT_FILE > GIT_INDEX_FILE > GIT_NO_REPLACE_OBJECTS > GIT_PREFIX -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html