On Wed, Feb 08, 2023 at 04:56:53PM +0100, Max Gautier wrote:
> I was trying to implement a pre-push hook to verify my commits are
> properly signed before pushing them, and stumbled upon the following
> output (which looks like a bug to me):
>
> $ git rev-list @{u}..HEAD --format='%G? %H'
> commit 9497d347b048dbea7f527624f815f7926594c4bc
> error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
>
> [...]
>
> While git log works and is able to retrieve the signatures
Yeah, I think this is a bug. The issue is that not every command loads
the config callback for every config option. This is how we
traditionally implemented the split between porcelain and plumbing
(e.g., user-facing "git diff" will parse and respect "color.diff", but
the scriptable "git diff-files" would not).
In this case, the gpg config has been pushed to its own handler, and a
few specific commands (like git-log) call it. I don't know if there is a
good reason to avoid loading the config in plumbing, or if it was simply
cargo-culted.
I didn't test, but I suspect the patch below would fix your problem:
diff --git a/config.c b/config.c
index 00090a32fc..7ac9f1f5bc 100644
--- a/config.c
+++ b/config.c
@@ -1881,6 +1881,14 @@ int git_default_config(const char *var, const char *value, void *cb)
if (starts_with(var, "core."))
return git_default_core_config(var, value, cb);
+ /*
+ * 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.") ||
starts_with(var, "author.") ||
starts_with(var, "committer."))
but it would need a bit more work:
1. Somebody would need to dig into the reasons, if any, for not
calling git_gpg_config() everywhere. It might be fine, but there
may be a good reason which we're now violating. Digging in the
history and looking at the code might yield some hints.
2. The individual calls to git_gpg_config() in other programs should
go away.
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?).
-Peff
