On Thu, Feb 18, 2016 at 11:29:09PM -0800, Jacob Keller wrote:
> I would prefer to either.. blacklist stuff like core.worktree, or
> whitelist a bunch of stuff that makes sense. In this case though, I
> would prefer to have an explicit test of credential.helper, but I
> don't know if any of our tests actually have a solid test case for
> "credential.helper was used in a clone. There may not be test
> infrastructure for this though, so your test might work well enough.
To trigger a credential fetch in actual use, you have to clone over
http. See the credential tests in t5550, for example.
> As for how to whitelist config to share with the submodule I am really
> not 100% sure, since we just clear GIT_CONFIG_PARAMETERS, and I think
> we'd need a specialized variant of clear_local_git_env_vars specific
> to submodule then.
Yeah, you'll have to parse, which is pretty painful. In C, you'd do
something like:
int submodule_config_ok(const char *var)
{
if (starts_with(var, "credential."))
return 1;
return 0;
}
int filter_submodule_config(const char *var, const char *value, void *data)
{
struct strbuf *out = data;
if (submodule_config_ok(var)) {
if (out->len)
strbuf_addch(out, ' ');
/* these actually probably need quoted all as * one string */
sq_quote_buf(out, var);
sq_quote_buf(out, "=");
sq_quote_buf(out, value);
}
return 0;
}
and then call it like:
struct strbuf filtered_config = STRBUF_INIT;
git_config_from_parameters(filter_submodule_config, &filtered_config);
argv_array_pushf(&child_process.env, "%s=%s",
CONFIG_DATA_ENVIRONMENT, filtered_config.buf);
but right now git-submodule.sh is all in shell. You'd probably need a
special helper from git-submodule--helper, though it might simply make
sense to put this off until the submodule code is fully ported to C.
-Peff
--
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