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. 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.
