Re: [PATCH v2 7/9] gpg-interface: introduce new config to select per gpg format program
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 16, 2018, 23:12 UTC
- Message-ID
- <xmqqo9f6rczt.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20180716222354.GA12482@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 22 quoted lines
> On Mon, Jul 16, 2018 at 02:56:34PM -0700, Junio C Hamano wrote: > >> >> I'm okay with us forcing "openpgp". That seems sane enough for now, and >> >> if people scream loudly, we can loosen it. >> > >> > Well, I specifically meant "are you sure subsections like this are a >> > good idea". But it seems like people think so? >> >> I admit that I did not even consider that there may be better tool >> than using subsections to record this information. What are the >> possibilities you have in mind (if you have one)? > > I don't think there is another tool except two-level options, like > "gpg.openpgpprogram" and "gpg.x509program". > > Although those are a bit ugly, I just wondered if they might make things > simpler, since AFAIK we are not planning to add more config options > here. Like gpg.x509.someotherflag, nor gpg.someothertool.program. > > Of course one reason _for_ the tri-level is that we might one day add > gpg.x509.someotherflag, and this gives us room to do it with less > awkwardness (i.e., a proliferation of gpg.x509someflag options).
Yes, and signingtool.<name>.<key> is probably a good (ultra-)long term direction. Preparing the code may be quite a lot of work that nobody may be interested in, and nothing other than the GPG family might materialize for a long time, but if we can cheaply prepare external interface less dependent on GPG/PGP, that by itself would be a good thing to have, I would guess.
Thanks.