BTW, a workaround is to pass a path to askpass script in the GIT_ASKPASS
Jens Lehmann <jens.lehm...@web.de> writes:
> 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
"Develop with pleasure!"
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