I haven't looked much into $subject, but there's an interesting regression in 2ca245f8be5 (csum-file.h: increase hashfile buffer size, 2021-05-18) where it fails with -v, but not --verbose-log. Discovered while running it manually. This is a regression in v2.33.0 (not v2.34.0!), so nothing urgent, and this is pretty obscure anyway. For the original change see: https://lore.kernel.org/git/64ffddd791160895b8e6730ebcddfac8458653f2.1621362768.git.gitgitgadget@xxxxxxxxx/ To reproduce it: make test T=t4216-log-bloom.sh GIT_TEST_OPTS=-v DEFAULT_TEST_TARGET=test Removing the -v, or making it --verbose-log will make it succeed. It fails on: + GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS=10 GIT_TRACE2_EVENT=/home/avar/g/git/t/trash directory.t4216-log-bloom/limits/trace git commit-graph write --reachable --changed-paths + test_max_changed_paths 10 trace + grep "max_changed_paths":10 trace error: last command exited with $?=1 not ok 135 - correctly report changes over limit If it's run with/without a debugging shimmy to save away the "trace" we can see that it doesn't include the max_changed_paths trace2 payload with -v. I.e. for some reason we either don't run trace2_bloom_filter_settings(), or don't log that data in the same way. It's probably easy to figure out for someone familiar with this code, but I couldn't see it from some quick skimming. Hence this E-Mail. FYI This is our only failure when running the whole test suite with -j1 -x (I didn't test a full run with just -v, takes a while, I was using -j1 to get sensible output at the end without needing to scroll up).
