On Tue, Nov 24 2020, Patrick Steinhardt wrote:
...some more feedback.
> +GIT_CONFIG_COUNT,GIT_CONFIG_KEY_<n>,GIT_CONFIG_VALUE_<n>::
> + If GIT_CONFIG_COUNT is set to a positive number, all environment pairs
> + GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be
> + added to the process's runtime configuration. The config pairs are
> + zero-indexed. Any missing key or value is treated as an error. An empty
> + GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no
> + pairs are processed. Config entries set this way have command scope,
> + but will be overridden by any explicit options passed via `git -c`.
Perhaps work in some/all of some version of these:
- There's also a GIT_CONFIG_PARAMETERS variable, which is considered
internal to Git itself. Users are expected to set these.
--> I.e. even if we're not going to support some format for
--> GIT_CONFIG_PARAMETERS document what it is.
- This is analogous to the pre-receive `GIT_PUSH_OPTION_*` variables
(see linkgit:githooks[5]), but unlike those the `-c` option to
linkgit:git(1) does not set `GIT_CONFIG_*`.
- Saying "command scope" here I think is wrong/misleading. If I didn't
know how this worked I'd expect the first git process to see it to
delete it from the env, so e.g. the "fetch" command would see it, but
not the "gc" it spawned (different commands). Maybe just say "the
scope of these is as with other GIT_* environment variables, they'll
be inherited by subprocesses".
> diff --git a/cache.h b/cache.h
> index c0072d43b1..8a36146337 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -472,6 +472,7 @@ static inline enum object_type object_type(unsigned int mode)
> #define TEMPLATE_DIR_ENVIRONMENT "GIT_TEMPLATE_DIR"
> #define CONFIG_ENVIRONMENT "GIT_CONFIG"
> #define CONFIG_DATA_ENVIRONMENT "GIT_CONFIG_PARAMETERS"
> +#define CONFIG_COUNT_ENVIRONMENT "GIT_CONFIG_COUNT"
I was wondering if this shouldn't be "GIT_CONFIG_KEY_COUNT" to be
consistent with the push options environment, but on a closer look we
have:
- GIT_CONFIG_COUNT
- GIT_CONFIG_KEY_N
- GIT_CONFIG_VALUE_N
- GIT_PUSH_OPTION_COUNT
- GIT_PUSH_OPTION_N
So I guess that makes sense & is consistent since we'd like to split the
key-value here to save the user the effort of figuring out which "="
they should split on.
> - if (!env)
> - return 0;
> -
Re the indent question to make the diff more readable question Junio
had: could set some "do we have this or that" variables here to not
reindent the existing code, but maybe not worth the effort...
> - if (sq_dequote_to_argv(envw, &argv, &nr, &alloc) < 0) {
> - ret = error(_("bogus format in %s"), CONFIG_DATA_ENVIRONMENT);
> - goto out;
> + count = strtoul(env, &endp, 10);
> + if (*endp) {
> + ret = error(_("bogus count in %s"), CONFIG_COUNT_ENVIRONMENT);
> + goto out;
> + }
> + if (count > INT_MAX) {
> + ret = error(_("too many entries in %s"), CONFIG_COUNT_ENVIRONMENT);
> + goto out;
> + }
> +
> + for (i = 0; i < count; i++) {
> + const char *key, *value;
> +
> + strbuf_addf(&envvar, "GIT_CONFIG_KEY_%d", i);
> + key = getenv(envvar.buf);
> + if (!key) {
> + ret = error(_("missing config key %s"), envvar.buf);
> + goto out;
> + }
> + strbuf_reset(&envvar);
> +
> + strbuf_addf(&envvar, "GIT_CONFIG_VALUE_%d", i);
> + value = getenv(envvar.buf);
> + if (!value) {
> + ret = error(_("missing config value %s"), envvar.buf);
> + goto out;
> + }
> + strbuf_reset(&envvar);
> +
> + if (config_parse_pair(key, value, fn, data) < 0) {
> + ret = -1;
> + goto out;
> + }
> + }
> }
>
> - for (i = 0; i < nr; i++) {
> - if (git_config_parse_parameter(argv[i], fn, data) < 0) {
> - ret = -1;
> + env = getenv(CONFIG_DATA_ENVIRONMENT);
> + if (env) {
> + int nr = 0, alloc = 0;
> +
> + /* sq_dequote will write over it */
> + envw = xstrdup(env);
> +
> + if (sq_dequote_to_argv(envw, &argv, &nr, &alloc) < 0) {
> + ret = error(_("bogus format in %s"), CONFIG_DATA_ENVIRONMENT);
> goto out;
> }
> +
> + for (i = 0; i < nr; i++) {
> + if (git_config_parse_parameter(argv[i], fn, data) < 0) {
> + ret = -1;
> + goto out;
> + }
> + }
> }
>
> out:
> + strbuf_release(&envvar);
> free(argv);
> free(envw);
> cf = source.prev;
> diff --git a/environment.c b/environment.c
> index bb518c61cd..e94eca92f3 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -116,6 +116,7 @@ const char * const local_repo_env[] = {
> ALTERNATE_DB_ENVIRONMENT,
> CONFIG_ENVIRONMENT,
> CONFIG_DATA_ENVIRONMENT,
> + CONFIG_COUNT_ENVIRONMENT,
> DB_ENVIRONMENT,
> GIT_DIR_ENVIRONMENT,
> GIT_WORK_TREE_ENVIRONMENT,
> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> index 825d9a184f..8c90cca79d 100755
> --- a/t/t1300-config.sh
> +++ b/t/t1300-config.sh
> @@ -1316,6 +1316,107 @@ test_expect_success 'detect bogus GIT_CONFIG_PARAMETERS' '
> git config --get-regexp "env.*"
> '
>
> +test_expect_success 'git config handles environment config pairs' '
I was wondering if the patch would keep the current
GIT_CONFIG_PARAMETERS or replace it entirely with the new facility.
On the one hand it would make sense to just replace
GIT_CONFIG_PARAMETERS, we could make this code loop over the new values.
On the other hand, and this is an edge case I hadn't considered before,
any change to the semantics of GIT_CONFIG_PARAMETERS means that e.g. a
fetch->gc spawning would break in the face of a concurrent OS update to
/usr/bin/git, since "fetch" and "gc" might be of differing versions
