On 6/4/2021 9:28 PM, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@xxxxxxxxx> ... > +test_expect_merge_algorithm failure failure 'Objects downloaded for single relevant rename' ' > + test_setup_repo && > + git clone --sparse --filter=blob:none "file://$(pwd)/server" objects-single && > + ( > + cd objects-single && > + > + git rev-list --objects --all --missing=print | > + grep '\?' >missing-objects-before && > + > + git checkout -q origin/A && > + > + GIT_TRACE2_PERF="$(pwd)/trace.output" git -c merge.directoryRenames=true merge --no-stat --no-progress origin/B-single && nit: this long line could be split up with \ marks. > + > + # Check the number of objects we reported we would fetch > + cat >expect <<-EOF && > + ..........fetch_count:2 > + ......fetch_count:1 I'm concerned that the number of dots here could change for various reasons (e.g. adding regions). Could the 'cut' below cut everything after the dots, so we only care about "fetch_count:X"? > + EOF > + grep fetch_count trace.output | cut -d "|" -f 9 >actual && > + test_cmp expect actual && > + > + # Check the number of fetch commands exec-ed > + grep d0.*fetch.negotiationAlgorithm trace.output >fetches && > + test_line_count = 2 fetches && > + > + git rev-list --objects --all --missing=print | > + grep ^? >missing-objects-after && > + test_cmp missing-objects-before missing-objects-after | > + grep "^[-+]?" >found-and-new-objects && > + # We should not have any NEW missing objects > + ! grep ^+ found-and-new-objects && > + # Fetched 2+1=3 objects, so should have 3 fewer missing objects > + test_line_count = 3 found-and-new-objects > + ) > +' Generally, this idea of using trace2 to determine internal activity that affects performance is a good one. The balance to strike is to ensure that future changes don't suffer too much due to the how rigid the tests are. The dots are the only example of a way to relax these tests a bit more. Thanks, -Stolee
