On 1/6/2021 4:40 PM, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Derrick Stolee <stolee@xxxxxxxxx> writes: >> >>>> I wonder if "false" or "exit 1" would fit the bill. In any case, a >>>> comment may help, perhaps? >>>> >>>> test_expect_success 'do nothing and succeed on empty/missing config' ' >>>> # if this runs even once, "false" ensures a failure >>>> git for-each-repo --config=bogus.config -- false >>>> ' >>> >>> I can add a comment, but keep in mind that this example would run the >>> subcommand as "git false". This isn't intended as an arbitrary script >>> runner, but a "please run the same Git command on a list of repos". >> >> Ah, that is a good point. >> >> The comment needs to explain: >> >> # the command fails if it attempts to run even once because >> # 'git false' does not exist >> >> and at that point, it does not have to be spelled 'false'. It could >> be 'no-such-git-subcommand' (and I wonder if that makes the comment >> unnecessary). >> >> That reminds me. If I have ~/bin/git-false and ~/bin on my $PATH, >> would this test fail to catch breakage? > > Yes, I think $PATH in the test environment starts from the original > $PATH and modified only by prepending, so my ~/bin/git-false would > kick in. We cannot reliably depend on the absence of a subcommand. > > We can instead use > > # the whole thing would fail if for-each-ref iterated even > # once, because 'git help --no-such-option' would fail > git for-each-ref --config=<var> -- help --no-such-option > > and I think that would be much more reliable; if an invocation of > "git help" inside our test suite fails to refer to the "git help" > from the version of Git being tested, we already have a serious > problem. A very good point. I'll include this in v3. Thanks, -Stolee
