Re: [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program
- Date: Tue, 10 Jul 2018 12:54:13 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program
On Tue, Jul 10, 2018 at 10:52:29AM +0200, Henning Schild wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ac373e3f4..c0bd80954 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1832,6 +1832,11 @@ gpg.format::
> Specifies which key format to use when signing with `--gpg-sign`.
> Default is "openpgp", that is also the only supported value.
> + Use this to customize the program used for the signing format you
> + chose. (see gpg.program) gpg.openpgp.program is a synonym for the
> + legacy gpg.program.
This seems like a good step forward. This is similar to the
signingtool.$name.program I proposed earlier, but keeping it specific to
gpg, which makes sense.
On the other hand, do we anticipate the user ever being able to add
gpg.foo.program? I don't think so; we'll provide a limited set of
options. So we _could_ go with "gpg.openpgpProgram" or similar, and
later add "gpg.x509Program".
And one reason to do so might be...
> diff --git a/gpg-interface.c b/gpg-interface.c
> index ac2df498d..65098430f 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -179,7 +179,7 @@ int git_gpg_config(const char *var, const char *value, void *cb)
> return git_config_string(&gpg_format, var, value);
> - if (!strcmp(var, "gpg.program"))
> + if (!strcmp(var, "gpg.program") || !strcmp(var, "gpg.openpgp.program"))
> return git_config_string(&gpg_formats[PGP_FMT].program, var,
We normally match config keys with strcmp() because the config machinery
will have already normalized them to lowercase. But in Git's config
format, the subsection (the middle in a three-dot name) is less
restricted and is case-sensitive.
Should we allow:
program = whatever
given that we allow:
format = OpenPGP
? I think just using strcasecmp() here would be sufficient. But I wonder
if it is a symptom of using the wrong tool (subsections) when we don't