# Unexpected effect of log.showSignature on tformat:%H. 5 messages from 2024-11-19 to 2024-11-21. Participants: Niels Möller, Junio C Hamano, brian m. carlson. Thread: https://gitlist.dev/t/62513 ## Niels Möller, 2024-11-19 09:17 Subject: Unexpected effect of log.showSignature on tformat:%H. Message-ID: <87cyirtweq.fsf@localhost> URL: https://gitlist.dev/e/87cyirtweq.fsf%40localhost ``` I had expected the output of git show -s --format='tformat:%H' to be always the same, and was surprised to find that scripts using this construction started to fail after I set log.showSignature true. See filled out bugreport form below, including a repro script. Regards, /Niels Möller Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) git config --global log.showSignature true I'm trying this out to get to see in git log which commits are signed. What did you expect to happen? (Expected behavior) That git show -s --format='tformat:%H' SOME_COMMIT should still output the commit hash and nothing more. What happened instead? (Actual behavior) I get an extra "No signature" line in the output (on stdout, not stderr), when looking at a signed commit. What's different between what you expected and what actually happened? The extra output line. Anything else you want to add: Here's a small script to reproduce the problem: -----8<----- #! /bin/sh set -eu export GIT_CONFIG_GLOBAL="$(pwd)/git.config" git config --global log.showSignature true git clone https://git.glasklar.is/glasklar/trust/audit-log.git cd audit-log hash=$(git show -s --format='tformat:%H' e36424e5688572c196d658a5df8c04c20de7606a) echo "Hash is: |$hash|" -----8<----- This is what it looks when I run it: -----8<----- $ ./repro.sh Cloning into 'audit-log'... remote: Enumerating objects: 143, done. remote: Counting objects: 100% (8/8), done. remote: Compressing objects: 100% (8/8), done. remote: Total 143 (delta 1), reused 0 (delta 0), pack-reused 135 (from 1) Receiving objects: 100% (143/143), 347.00 MiB | 107.22 MiB/s, done. Resolving deltas: 100% (59/59), done. error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification Hash is: |No signature e36424e5688572c196d658a5df8c04c20de7606a| -----8<----- I would have expected the output Hash is: |e36424e5688572c196d658a5df8c04c20de7606a| [System Info] git version: git version 2.39.5 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 compiler info: gnuc: 12.2 libc info: glibc: 2.40 $SHELL (typically, interactive shell): /bin/bash [Enabled Hooks] not run from a git repository - no hooks to show ``` ## Junio C Hamano, 2024-11-19 09:37 Subject: Re: Unexpected effect of log.showSignature on tformat:%H. Message-ID: URL: https://gitlist.dev/e/xmqqmshvd0nn.fsf%40gitster.g In-Reply-To: <87cyirtweq.fsf@localhost> ``` Niels Möller writes: > I had expected the output of git show -s --format='tformat:%H' to be > always the same, and was surprised to find that scripts using this > construction started to fail after I set log.showSignature true. It is a bit unexpected, but knowing how the command options evolved, it is not all that surprising X-<. If you are using --format, you are expected to use the %G placeholder and friends when you are interested in signatures. The --show-signature option is unaware of the other formatting options like --pretty={short,oneline,fuller, so it is understandable (not "expected") what you are seeing. ``` ## Niels Möller, 2024-11-19 10:06 Subject: Re: Unexpected effect of log.showSignature on tformat:%H. Message-ID: <878qtftu5e.fsf@localhost> URL: https://gitlist.dev/e/878qtftu5e.fsf%40localhost In-Reply-To: ``` Junio C Hamano writes: > It is a bit unexpected, but knowing how the command options evolved, > it is not all that surprising X-<. If you are using --format, you > are expected to use the %G placeholder and friends when you are > interested in signatures. The thing is, I'm generally interested in signatures when using git interactively (that's why I enabled log.showSignature globally). But then I have a scripted usecase that has a tag name, and needs to query the corresponding commit hash, and in that context, I don't care about signatures at all. The docs for git show say that %H expands to the commit hash, which is exactly what I want. I didn't know about the %G formats, but after a quick look at the docs, I don't think they solves that problem. I can work around this problem by using "export GIT_CONFIG_GLOBAL=/dev/null" in the script, which I guess might be generally good practice when using git in scripts? But I still think it would be useful if there were an easy and reliable way to get from tag to commit hash, regardless of the user's config settings. Regards, /Niels Möller ``` ## brian m. carlson, 2024-11-19 22:14 Subject: Re: Unexpected effect of log.showSignature on tformat:%H. Message-ID: URL: https://gitlist.dev/e/Zz0NsaM-KFRXzBp6%40tapette.crustytoothpaste.net In-Reply-To: <87cyirtweq.fsf@localhost> ``` On 2024-11-19 at 09:17:33, Niels Möller wrote: > I had expected the output of git show -s --format='tformat:%H' to be > always the same, and was surprised to find that scripts using this > construction started to fail after I set log.showSignature true. > > See filled out bugreport form below, including a repro script. > > Regards, > /Niels Möller > > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > > git config --global log.showSignature true > > I'm trying this out to get to see in git log which commits are > signed. > > What did you expect to happen? (Expected behavior) > > That git show -s --format='tformat:%H' SOME_COMMIT > should still output the commit hash and nothing more. git show is a porcelain, and it can be affected by options, such as `log.showSignature`. If you want predictable behaviour, you need a plumbing command, whose behaviour isn't affected by configuration in this way. The equivalent to what you've requested is this: git rev-list --no-commit-header -1 -s --format='tformat:%H' SOME_COMMIT I've confirmed that works correctly even if `log.showSignature` is set. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ``` ## Niels Möller, 2024-11-21 09:08 Subject: Re: Unexpected effect of log.showSignature on tformat:%H. Message-ID: <874j41t0mi.fsf@localhost> URL: https://gitlist.dev/e/874j41t0mi.fsf%40localhost In-Reply-To: ``` "brian m. carlson" writes: > git show is a porcelain, and it can be affected by options, such as > `log.showSignature`. If you want predictable behaviour, you need a > plumbing command, whose behaviour isn't affected by configuration in > this way. The equivalent to what you've requested is this: > > git rev-list --no-commit-header -1 -s --format='tformat:%H' SOME_COMMIT > > I've confirmed that works correctly even if `log.showSignature` is set. Thanks! It seems the way to understand this is that git show can display a bunch of different things, depending on configuration, and --tformat affects only one of potentially many output lines. So git rev-list solves this problem. My script (which creates a file archive, in a reproducible fashion, from a list if git repos and (signed) tags) uses a few more git commands: git clone git ls-files git -c gpg.ssh.allowedSignersFile=... tag --verify git submodule Of these, it appears only ls-files is listed as a "plumbing" command. I wonder if I still need to stick to GIT_CONFIG_GLOBAL=/dev/null to avoid surprises for the clone, tag and submodule commands? Any advice appreciated. Regards, /Niels ```