Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> + /* >> + * yikes, this needs to come early in the function because it >> + * also handles user.signingkey, which would otherwise get >> + * shunted to git_ident_config() below >> + */ >> + if (git_gpg_config(var, value, cb) < 0) >> + return -1; >> ... >> if (starts_with(var, "user.") || >> ... >> 3. It's possible some refactoring may let us avoid the "yikes" comment >> above (e.g., should user.signingkey just go into the normal ident >> config handler?). > > Hindsight is golden---if this were called gpg.signingkey we wouldn't > be having this discussion X-<. I wonder if gpg-interface functions can and should be taught to initialize themselves lazily without relying on the usual git_config(git_gpg_config) sequence. I.e. the first call to sign_buffer(), check_signature(), get_signing_key_id(), etc. would internally make a git_config(git_gpg_config) call, with the current callers of git_config(git_gpg_config) removed.
