Hmm. I don't think that technique gives complete coverage. There are other scripts (e.g., filter-branch) that call a bare "perl" (not PERL_PATH), which presumably pass the tests even though they'd break in a real-world system without perl. In fact, many scripts used to do this before fcb06a8d54 (use @@PERL@@ in built scripts, 2013-10-28). I don't think the effects on NO_PERL were really considered there; it was more about finding the right perl.
Hmm, filter-branch calls bare "perl", not @@PERL@@ or Perl at an absolute path. At first I thought that made it pass when "perl" is on the PATH in tests. But even when I replace those with @@PERL@@, the test still pass. I will investigate further.
I think NO_PERL has historically mostly meant "do not build or install perl scripts", and not "everything ought to run fine without perl". We've generally assumed you can run vanilla perl snippets from the command line the same way you'd run awk or sed (and the tests use this extensively, which is why you have to set PERL_PATH again to run them) That said, most of those casual uses of perl in actual built scripts have gone away because the shell scripts have gone away. It looks like filter-branch, request-pull, and instaweb are the last holdouts. So maybe we should be treating NO_PERL as disabling those scripts, too. But then, should we be doing more to make it clear that those scripts are broken in a NO_PERL build? Who knows what happens if you run filter-branch without any perl available?
My understanding was that NO_PERL controlled the runtime dependencies of Git, and that the tests require Perl either way. Of course, without Perl any scripts that depend on it can't be used, but like you say, there are few of them left. I think it would make sense to not install those scripts when NO_PERL=1. Should I make a patch to change that in the makefile?
Best, Ruud
