I've noticed that in v2.19.1, when using git to pretty print information about the signature, if git cannot find gpg (e.g. "git config gpg.program nogpg"), it prints an error to stderr: $ git show -s --pretty=%G? fatal: cannot run nogpg: No such file or directory N When I build from master, that no longer happens: $ ../git/git show -s --pretty=%G? N Is this intentional behavior, i.e. something I can count on being the case in future releases? Or should I treat this as a bug report? (I have no opinion on whether this should be a feature or a bug, but I'm working on a patch whose implementation may look very different based on the answer to this question.) I've dug around the code and come up with the notion that setting child_process.silent_exec_failure = 1 is the usual way of suppressing this message. But "git log -S silent_exec_failure v2.19.1..master" shows no changes that could have caused this, nor can I find any mention of it in release notes. It occurs for just about any interaction with GPG that I can find, whether signing tags or commits, or verifying signatures through pretty-print or git verify-commit or git merge --log or git merge --verify-signatures. In all these cases, v2.19.1 issues "fatal: cannot run nogpg: No such file or directory" to stderr, while a binary built from master behaves the same in all respects (including other errors when trying to sign) except that it's missing the "fatal:" message. This behavior makes sense in a lot of ways. If you're interested in verifying commit signatures, it's hard to imagine needing a reminder to install the program it depends on (though the error might help you identify bad configuration for "gpg.program"). Conversely, if you're not familiar with crypto software and try git log --format=%G? or git verify-commit for fun, "Fatal: cannot run gpg" may look like a bug. So I can definitely imagine justifications for this. Nonetheless, the fact that I can't find documentation for the change smells funny. I'd be very grateful if somebody on this list could tell me whether I can count on this behavior in the future, or whether my code should account for a possibility that this behavior could change in the future. I'd also be very very interested to see in what commit(s) this change occurred. Thanks in advance! John Passaro (917) 678-8293
