Am 16.11.2013 22:42, schrieb Thomas Rast:
> Dmitry Neverov <dmitry.neve...@jetbrains.com> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html