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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2017, 18:27 UTC
Message-ID: <xmqq4m12izmd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170113024842.GA20572@starla>

Eric Wong <e@80x24.org> writes:

Show 8 quoted lines

> Pat Pannuto <pat.pannuto@gmail.com> wrote:
>> You may still want the 1/2 patch in this series, just to make things
>> internally consistent with "-w" vs "use warnings;" inside git's perl
>> scripts.
>
> No, that is a step back.  "-w" affects the entire process, so it
> spots more potential problems.  The "warnings" pragma is scoped
> to the enclosing block, so it won't span across files.

OK, so with "-w", we do not have to write "use warnings" in each of our files to get them checked. It is handy when we ship our own libs (e.g. Git.pm) that are used by our programs.

If something we write outselves trigger a false-positive, we can work it around with "no warnings;" in the smallest block that encloses the offending code in the worst case, or just rephrase it in a way that won't trigger a false-positive.

If something we _use_ from a third-party is not warnings-clean, there is no easy way to squelch them if we use "-w", which is a potential downside, isn't it? I do not know how serious a problem it is in practice. I suspect that the core package we use from perl distribution are supposed to be warnings-clean, but we use a handful of things from outside the core and I do not know what state they are in.