* Unexpected effect of log.showSignature on tformat:%H.
@ 2024-11-19 9:17 Niels Möller
2024-11-19 9:37 ` Junio C Hamano
2024-11-19 22:14 ` brian m. carlson
0 siblings, 2 replies; 5+ messages in thread
From: Niels Möller @ 2024-11-19 9:17 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Unexpected effect of log.showSignature on tformat:%H.
2024-11-19 9:17 Unexpected effect of log.showSignature on tformat:%H Niels Möller
@ 2024-11-19 9:37 ` Junio C Hamano
2024-11-19 10:06 ` Niels Möller
2024-11-19 22:14 ` brian m. carlson
1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2024-11-19 9:37 UTC (permalink / raw)
To: Niels Möller; +Cc: git
Niels Möller <nisse@glasklarteknik.se> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Unexpected effect of log.showSignature on tformat:%H.
2024-11-19 9:37 ` Junio C Hamano
@ 2024-11-19 10:06 ` Niels Möller
0 siblings, 0 replies; 5+ messages in thread
From: Niels Möller @ 2024-11-19 10:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Unexpected effect of log.showSignature on tformat:%H.
2024-11-19 9:17 Unexpected effect of log.showSignature on tformat:%H Niels Möller
2024-11-19 9:37 ` Junio C Hamano
@ 2024-11-19 22:14 ` brian m. carlson
2024-11-21 9:08 ` Niels Möller
1 sibling, 1 reply; 5+ messages in thread
From: brian m. carlson @ 2024-11-19 22:14 UTC (permalink / raw)
To: Niels Möller; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Unexpected effect of log.showSignature on tformat:%H.
2024-11-19 22:14 ` brian m. carlson
@ 2024-11-21 9:08 ` Niels Möller
0 siblings, 0 replies; 5+ messages in thread
From: Niels Möller @ 2024-11-21 9:08 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
"brian m. carlson" <sandals@crustytoothpaste.net> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-11-21 9:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-19 9:17 Unexpected effect of log.showSignature on tformat:%H Niels Möller
2024-11-19 9:37 ` Junio C Hamano
2024-11-19 10:06 ` Niels Möller
2024-11-19 22:14 ` brian m. carlson
2024-11-21 9:08 ` Niels Möller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).