"Kyle Lippincott via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Kyle Lippincott <spectral@xxxxxxxxxx> > > The `grep` statement in this test looks for `d0.*<string>`, attempting > to filter to only show lines that had tabular output where the 2nd > column had `d0` and the final column had a substring of > [`git -c `]`fetch.negotiationAlgorithm`. These lines also have > `child_start` in the 4th column, but this isn't part of the condition. > > A subsequent line will have `d1` in the 2nd column, `start` in the 4th > column, and `/path/to/git/git -c fetch.negotiationAlgorihm` in the final > column. If `/path/to/git/git` contains the substring `d0`, then this > line is included by `grep` as well as the desired line, leading to an > effective doubling of the number of lines, and test failures. > > Tighten the grep expression to require `d0` to be surrounded by spaces, > and to have the `child_start` label. OK. I think I actually misinterpreted what you meant with these changes. It is not what the patterns are picking. It is some _other_ trace entry we do not necessarily care about, like label:do_write_index that has the path to the .git/index.lock file, that can accidentally contain d0, that can be picked up with a pattern that is too loose. So it really didn't have to clarify what it is looking for, as it would not help seeing what false positives the patterns are designed to avoid matching. Sorry about that. Will queue.
