Hi,

Ruud van Asseldonk wrote:

Jeff King wrote:

quoted

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)

We've definitely held the stance that NO_PERL doesn't mean to disable
perl in tests.  For casual use of perl in installed shell scripts, on
the other hand, I suspect it was more that we forgot about them than
that we had decided one way or another. :)

[...]

quoted

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?

Yes, that sounds good to me.  (The status quo also seems fine to me,
but I like that this proposed approach would simplify things a
little.)

Thanks for working on this, and sorry for the earlier noise.

Sincerely,
Jonathan