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: > >> 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/ > > Interesting. This patch makes it go away (the "5" is cargo-culted from > earlier in the script): ... > # 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@xxxxxxxxx/
