Hi Jonathan, On Mon, 27 Apr 2020, Jonathan Tan wrote: > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh > index baa1a99f45..961cd6beec 100755 > --- a/t/t5500-fetch-pack.sh > +++ b/t/t5500-fetch-pack.sh > @@ -385,6 +385,24 @@ test_expect_success 'clone shallow with packed refs' ' > test_cmp count8.expected count8.actual > ' > > +test_expect_success 'in_vain not triggered before first ACK' ' > + rm -rf myserver myclient trace && > + git init myserver && > + test_commit -C myserver foo && > + git clone "file://$(pwd)/myserver" myclient && > + > + # MAX_IN_VAIN is 256. Because of batching, the client will send 496 > + # (16+32+64+128+256) commits, not 256, before giving up. So create 496 > + # irrelevant commits. > + test_commit_bulk -C myclient 496 && > + > + # The new commit that the client wants to fetch. > + test_commit -C myserver bar && > + > + GIT_TRACE_PACKET="$(pwd)/trace" git -C myclient fetch --progress origin && > + test_i18ngrep "Total 3 " trace This just failed in one of the Pipelines I monitor: https://github.com/git-for-windows/git-sdk-64/runs/648253955?check_suite_focus=true The short of it is: -- snip -- [...] packet: sideband< \2Enumerating objects: 4, done. packet: sideband< \2Counting objects: 25% (1/4)\15Counting objects: 50% (2/4)\15Counting objects: 75% (3/4)\15Counting objects: 100% (4/4)\15Counting obj packet: sideband< \2ects: 100% (4/4), done.Compressing objects: 50% (1/2)\15Compressing objects: 100% (2/2)\15Compressing objects: 100% (2/2), done.T packet: sideband< \2otal 3 (delta 0), reused 0 (delta 0), pack-reused 0 packet: sideband< PACK ... packet: upload-pack> 0000 packet: sideband< 0000 ++ return 1 error: last command exited with $?=1 t/t5500-fetch-pack.sh:388: error: not ok 43 - in_vain not triggered before first ACK # # rm -rf myserver myclient trace && # git init myserver && # test_commit -C myserver foo && # git clone "file://$(pwd)/myserver" myclient && # # # MAX_IN_VAIN is 256. Because of batching, the client will send 496 # # (16+32+64+128+256) commits, not 256, before giving up. So create 496 # # irrelevant commits. # test_commit_bulk -C myclient 496 && # # # The new commit that the client wants to fetch. # test_commit -C myserver bar && # # GIT_TRACE_PACKET="$(pwd)/trace" git -C myclient fetch --progress origin && # test_i18ngrep "Total 3 " trace -- snap -- In other words, that `test_i18ngrep` assumes incorrectly that "Total 3" will be found in the trace, but the sideband is totally allowed to cut through it and deliver it in different packets. This makes t5500 flaky. Ciao, Johannes > +' > + > test_expect_success 'fetch in shallow repo unreachable shallow objects' ' > ( > git clone --bare --branch B --single-branch "file://$(pwd)/." no-reflog && > -- > 2.26.2.303.gf8c07b1a785-goog > > >
