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

Junio C Hamano [off-list ref] wrote:

Eric Wong [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] wrote:

quoted

Eric Wong [off-list ref] writes:

quoted

Pat Pannuto [off-list ref] wrote:

quoted

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.