On 2024.02.01 15:08, Josh Steadmon wrote: > On 2024.01.16 15:18, Junio C Hamano wrote: > > Josh Steadmon <steadmon@xxxxxxxxxx> writes: > > > Second "--(no-)require-shell-test-pattern" bypasses the check that the > > > test filenames match the expected t####-*.sh pattern. > > > > This one I am not so sure. Do we still have situations where > > erroring out when fed a non t[0-9][0-9][0-9][0-9]-*.sh script is > > problematic? IOW, do we need to keep it as conditional? > > > > ... goes and looks ... > > > > Ah, this variable/option is misnamed and that is what invited the > > above nonsense question out of me. The logic this option disables > > does not "require" (and error out if the requirement is not met); it > > is used in a loop over "ls *" and "filtering" files out that are not > > the numbered scripts. > > > > But that confusion makes me wonder if non-script side of tests would > > also want some filtering in the longer run, even if the directory we > > feed to "test-tool run" happens to contain nothing but what we want > > to run right now. I wonder if we instead want a variable that holds > > a pattern used to match programs readdir() discovers and skip those > > that do not match the pattern? Its default value may be something > > like "t[0-9][0-9][0-9][0-9]-*.sh" but alternatively you can give, > > say, "*" to pass everything, or something like that. > > The original implementation and this series both still allow passing > additional patterns on the command line. Only tests matching the > hardcoded t[0-9][0-9][0-9][0-9]-*.sh pattern plus all the command-line > patterns will be run. The new flag just bypasses the hardcoded pattern. Actually, I misspoke here. The test must match the hardcoded pattern plus at least one of the command-line patterns (if any were provided). > Given that V2 will already be changing in non-backwards-compatible ways, > I think it makes the most sense to just delete the hardcoded pattern and > require callers to provide it if they want it. Given that it sounds like the testsuite functionality is not really used at the moment, I still feel OK with changing the pattern matching logic here for V2.
