On Sat, Jan 14, 2017 at 10:31:34AM +, Eric Wong wrote:
> Jeff King 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 err
Jeff King 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 respons
On Fri, Jan 13, 2017 at 06:52:46PM +, Eric Wong wrote:
> > 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 suspec
Junio C Hamano wrote:
> Eric Wong writes:
> > Junio C Hamano wrote:
> >> Eric Wong writes:
> >> > Pat Pannuto 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.
> >> >
Eric Wong writes:
> Junio C Hamano wrote:
>> Eric Wong writes:
>> > Pat Pannuto 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" a
Junio C Hamano wrote:
> Eric Wong writes:
> > Pat Pannuto 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
Eric Wong writes:
> Pat Pannuto 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.
Hi Eric,
On Fri, 13 Jan 2017, Eric Wong wrote:
> Johannes Schindelin wrote:
> > I guess I do not understand, still, what the difference is between using
> > -w and adding `use warnings` *very early* in the script... Could you give
> > an example where it makes a difference?
>
> "use warnings" w
Johannes Schindelin wrote:
> I guess I do not understand, still, what the difference is between using
> -w and adding `use warnings` *very early* in the script... Could you give
> an example where it makes a difference?
"use warnings" won't leak across files/modules. In the following
example, on
Hi Eric,
On Fri, 13 Jan 2017, Eric Wong wrote:
> Pat Pannuto 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
Hi Pat,
On Thu, 12 Jan 2017, Pat Pannuto 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.
Yes, I like that patch.
Ciao,
Johannes
Pat Pannuto 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 sco
Pat Pannuto writes:
> 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.
I do not think so. 1/2 is justified as a prerequisite of 2/2 and
needs a different log message, so cannot be used as is.
I'm happy to let this drop.
I've filed the missing perl library as a homebrew issue [1], so
hopefully this won't be an issue for folks in the future.
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.
Johannes Schindelin writes:
> So if this patch would make it into upstream Git, I would *have* to revert
> it in Git for Windows, adding to my already considerable maintenance burden.
I do not think we want "#!/usr/bin/env $language" in the upstream,
either.
Hi Pat,
On Thu, 12 Jan 2017, Pat Pannuto wrote:
> I'm not at all attached to changing all of them, just figured it made
> sense while I was here.
>
> Would a patch that changes only:
>
> git-add--interactive.perl | 2 +-
> git-archimport.perl | 2 +
I'm not at all attached to changing all of them, just figured it made
sense while I was here.
Would a patch that changes only:
git-add--interactive.perl | 2 +-
git-archimport.perl | 2 +-
git-cvsexportcommit.perl | 2 +-
git-cvs
Am 12.01.2017 um 06:51 schrieb Pat Pannuto:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index cf6fc926a..6d7b6c35d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/env perl
This change, and all others that
Depending on system configuration, /usr/bin/perl may not be the
preferred perl interpreter, use /usr/bin/env perl to invoke perl
instead to repsect user preferences.
In most cases this will not matter as any perl install will work,
but for applications such as git-format-patch, which may require
p
19 matches
Mail list logo
