git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git svn log: Use of uninitialized value $sha1_short

From
Jeff King <peff@peff.net>
Date
Oct 22, 2020, 02:56 UTC
Message-ID
<20201022025644.GA1480820@coredump.intra.peff.net>
In-Reply-To
<20201021222901.GK490427@camp.crustytoothpaste.net>
On Wed, Oct 21, 2020 at 10:29:01PM +0000, brian m. carlson wrote:
Show 10 quoted lines
> >   - I wonder if it's suitable for production use (i.e., would it become
> >     annoying when a newer version of perl issues a harmless warning;
> >     right now that's a minor inconvenience, but aborting the whole
> >     program might be a show-stopper).
> 
> No, that's not suitable for production use.  Perl does add new warnings
> from time to time and breaking things when Perl gets upgraded will
> definitely not make us the friends of Linux distros.  Doing this is like
> using -Werror: fine for your personal development needs, but not
> suitable for shipping to others.
OK, that matches my general sense.
Show 5 quoted lines
> We could run "perl -w" on each file and look for a single-line output
> with "OK"; that's what we did at a previous job.  However, any change we
> make here needs to be conditional on DEVELOPER, because otherwise anyone
> who needs to build an Git with a new version of Perl will potentially
> have a broken testsuite.

Yeah, I've done something similar as well. I agree it would be potentially annoying for distros building. But unlike the -Wall/-Werror distinction, where the builder may be annoyed by extra messages but the end result is presumably OK, this _does_ affect end users. I.e., if it triggers, it also means the users of your package are going to see annoying warnings. The change I'm proposing is just whether that's fatal or not.

So it might actually be of interest to distro builders to know that the version of Git they're building is going to produce annoying warnings. And the escape hatch there is likely not to turn warnings from fatal to non-fatal, but to suppress the particular warning entirely with a patch to the code.

I dunno. I admit I don't really care enough about our perl code in general (which I consider mostly legacy; I doubt we'd introduce new perl scripts lightly). So it may not even be worth putting a lot of effort into it. But it is unfortunate that this bug _could_ have been caught automatically but wasn't.

-Peff
Previous: brian m. carlsonNext: brian m. carlson
Message 6 of 11 in “git svn log: Use of uninitialized value $sha1_short”
  1. Nikos ChantziarasOct 21, 2020
  2. Jeff KingOct 21, 2020
  3. Junio C HamanoOct 21, 2020
  4. Jeff KingOct 21, 2020
  5. brian m. carlsonOct 21, 2020
  6. Jeff KingOct 22, 2020
  7. brian m. carlsonOct 21, 2020
  8. svn: use correct variable name for short OIDbrian m. carlson, Oct 22, 2020
  9. Jeff KingOct 22, 2020
  10. Jeff KingOct 22, 2020
  11. Junio C HamanoOct 22, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.