Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eric Wong <e@xxxxxxxxx> writes: > > Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Eric Wong <e@xxxxxxxxx> writes: > >> > Pat Pannuto <pat.pannuto@xxxxxxxxx> 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.