Re: git submodule should honor "-c credential.helper" command line argument

From: Jeff King <peff@peff.net>
Date: Feb 19, 2016, 04:30 UTC
Message-ID: <20160219043019.GA14764@sigill.intra.peff.net>
In-Reply-To: <CA+P7+xpHNHVSJnVg3HwiBjWxRdSpLXCsm3GpWst=BNyhLMVd5A@mail.gmail.com>

On Thu, Feb 18, 2016 at 05:15:54PM -0800, Jacob Keller wrote:

Show 7 quoted lines

> I am looking at this more and I am stuck as to how best to provide a
> test case.
> 
> I think the problem as stated above is pretty straight forward, we
> just want to stop clearing GIT_CONFIG_PARAMETERS but I can't find an
> easy way to test that we've done the right thing. There are no current
> tests for using a credential helper with submodule update right now.

If you just want to test that GIT_CONFIG_PARAMETERS is left untouched in the submodule, you can tweak any config setting that would impact the newly-cloned repo. E.g. this:

  unset GIT_COMMITTER_NAME
  git config --global user.name='Global Name'
  git -c user.name='Command-Line Name' clone repo-with-module foo
  head -1 foo/.git/logs/HEAD
  head -1 foo/.git/modules/sub/logs/HEAD

shows that the parent-level clone uses the "-c" name, but the submodule does not.

That being said, I am not sure this is the right solution. In the thread I linked earlier[1], Jens indicated he would prefer not to blindly share config with the submodules, and I think I agree. Or are you proposing to pick and choose the keys in GIT_CONFIG_PARAMETERS, and whitelist credential.*?

In that case, obviously my test example would not work, though I think that it might be fine to put "user.name" onto the whitelist (the things we really would worry about is stuff like "core.worktree" that clearly does not make sense to carry over into the submodule).

-Peff

[1] http://thread.gmane.org/gmane.comp.version-control.git/264840