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

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

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <e@80x24.org> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> Eric Wong <e@80x24.org> writes:
> >> > 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.
> >
> > Yes.  "use warnings" should be in our own libs in case other
> > people run without "-w"
> 
> Would it mean that we need both anyway?  That is, add missing "use
> warnings" without removing "-w" from she-bang line?

Yes, we keep "use warnings" other people may use, at least.
No harm in keeping that in top-level scripts, I guess.

> Speaking of Perl, I recall that somebody complained that we ship
> with and do use a stale copy of Error.pm that has been deprecated.
> I am not asking you to do so, but we may want to see somebody look
> into it (i.e. assessing the current situation, and if it indeed is
> desirable for us to wean ourselves away from Error.pm, update our
> codepaths that use it).

Agreed, I'd definitely prefer to move towards the basic eval/die
construct without relying on a bundled 3rd-party mechanism.
But we might need a migration path for out-of-tree users of
Git.pm (if any)...

I'm sure I've agreed this was a path we should be taking in the
past, but did something about it myself.  So yeah, maybe Pat or
somebody else interested can take care of this :)

Thanks.