On 11/25/2021 11:08 PM, Jeff King wrote:
On Thu, Nov 25, 2021 at 01:14:45PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
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@gmail.com/ (local)
Interesting. This patch makes it go away (the "5" is cargo-culted from
earlier in the script):
...
quoted hunk ↗ jump to hunk
# Commit has 7 file and 4 directory adds
GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS=10 \
+ GIT_TRACE2_EVENT_NESTING=5 \
GIT_TRACE2_EVENT="$(pwd)/trace" \
git commit-graph write --reachable --changed-paths &&
test_max_changed_paths 10 trace &&
...
The commit in question (2ca245f8be) puts the writing into a new trace2
region ("chunkfile"), so it makes sense that the nesting increases by
one. But what's interesting is that the nesting is different depending
on whether stderr is a terminal. I guess because the progress code
starts its own region.
The default nesting max for trace2 is 2. That seems kind of low given
this example, but I don't know enough about the tradeoffs to say what
bad things might happen if it's raised. But the above patch really seems
like a hack, and that this quiet omission would absolutely confuse real
users who are trying to use trace2 for debugging.
Thanks, both, for identifying the problem and the root cause. I have
sent a patch series [1] that sets a deeper GIT_TRACE2_EVENT_NESTING
across the test suite to avoid this kind of issue in the future (along
with removing the existing uses scattered across the tests).
Thanks,
-Stolee
[1] https://lore.kernel.org/git/pull.1085.git.1638193666.gitgitgadget@gmail.com/ (local)