Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

[Eric Wong <e@80x24.org>]

Jeff King <peff@peff.net> wrote:
> Just as a devil's advocate, why do we care about warnings in third-party
> modules? Or more specifically, why do _users_ who are running Git care
> about them? We cannot fix them in Git. A user may report the error to
> the module author, but the module author may not be responsive, or even
> may not be inclined to fix the problem (because they have a particular
> opinion on that warning).

Every user is a potential developer(*).  And I do feel
we (git developers) should be at least somewhat responsible
for helping maintain and fix the projects we depend on;
or moving to alternatives if we can't fix them.

There is a chance a newly-introduced warning in a 3rd-party
module points to a real problem with the way git uses it, too.
Having that warning would help us fix or workaround the bug
(either in git or the module).

I doubt any module author would be unresponsive to having a
localized "no warnings" for special cases.  AFAIK, "-w" is
widespread amongst Perl users (unlike Ruby in my experience).


(*) I feel that more strongly in the git case, and even more so
    for the Perl bits since the source is already on the user's
    machine.

> In the meantime, the user is stuck with an annoying warning message
> until Git is updated as you showed above. Why not just start there
> preemptively, and let module authors worry about their own warnings?

I'm not saying we blindly start using '-w' everywhere today.
But we may at least try it and see if it introduces new
warnings, first, and only enable '-w' when it it looks quiet
(and perhaps start working with module authors to fix warnings
 if not).

As a user, I'd rather have some indication of where something
might be wrong, than no warning at all when something does go
wrong.