Jeff King <peff@xxxxxxxx> 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.