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

Re: [PATCH v4 1/2] refs: introduce reftable backend

From
Jeff King <peff@peff.net>
Date
Feb 15, 2024, 05:39 UTC
Message-ID
<20240215053902.GF2821179@coredump.intra.peff.net>
In-Reply-To
<ZcRinffkQJNWyiGZ@tanuki>
On Thu, Feb 08, 2024 at 06:11:57AM +0100, Patrick Steinhardt wrote:
Show 11 quoted lines
> > > +	ret = reftable_writer_add_logs(writer, logs, logs_nr);
> > > +	if (ret < 0)
> > > +		goto done;
> > 
> > ...the first thing we do is write over it. I dunno if it's worth keeping
> > as a maintenance precaution, though (if the code after the loop changed
> > to omit that assignment, then setting "ret" would become important).
> 
> Yeah, I think this one we should keep. It's also a repeating pattern
> that we have in many other places, so it helps lower the mental burden
> when it looks similar to all the others.
That sounds quite reasonable to me.
Show 5 quoted lines
> > Both were noticed by Coverity (along with several other false
> > positives).
> 
> Is the Coverity instance publicly accessible? If not, can you maybe
> invite me so that I get a better feeling for them?

I don't think there's a way to make it publicly accessible. Probably I could invite you to the project if you sign up for a Coverity account. But it's a build of next plus my personal in-progress topics, which is probably not ideal for other people to look at.

There are instructions for setting up your own scan in a56b6230d0 (ci: add a GitHub workflow to submit Coverity scans, 2023-09-25). The unsaid part there is signing up for Coverity and registering a project to get the necessary tokens. Probably start here:

  https://scan.coverity.com/users/sign_up
but I don't remember the details.

The Actions workflow is in "master", so in theory we could register a project for git.git and get automatic builds when Junio pushes to 'next', etc. In practice I have found that it requires a human looking over the results, but if people at least had access they could poke around.

(I suspect it would also be easy to port the workflow over to run on GitLab CI, as well, if you wanted to).

-Peff
Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 22 of 23 in “refs: introduce reftable backend”
  1. 0/2 refs: introduce reftable backendPatrick Steinhardt, Jan 30, 2024
  2. 1/2 refs: introduce reftable backendPatrick Steinhardt, Jan 30, 2024
  3. Karthik NayakFeb 1, 2024
  4. Patrick SteinhardtFeb 2, 2024
  5. Patrick SteinhardtFeb 2, 2024
  6. 2/2 ci: add jobs to test with the reftable backendPatrick Steinhardt, Jan 30, 2024
  7. Junio C HamanoJan 30, 2024
  8. 0/2 refs: introduce reftable backendPatrick Steinhardt, Feb 2, 2024
  9. 1/2 refs: introduce reftable backendPatrick Steinhardt, Feb 2, 2024
  10. 2/2 ci: add jobs to test with the reftable backendPatrick Steinhardt, Feb 2, 2024
  11. Karthik NayakFeb 2, 2024
  12. Junio C HamanoFeb 3, 2024
  13. Patrick SteinhardtFeb 4, 2024
  14. 0/2 refs: introduce reftable backendPatrick Steinhardt, Feb 5, 2024
  15. 1/2 refs: introduce reftable backendPatrick Steinhardt, Feb 5, 2024
  16. 2/2 ci: add jobs to test with the reftable backendPatrick Steinhardt, Feb 5, 2024
  17. Karthik NayakFeb 5, 2024
  18. 0/2 refs: introduce reftable backendPatrick Steinhardt, Feb 7, 2024
  19. 1/2 refs: introduce reftable backendPatrick Steinhardt, Feb 7, 2024
  20. Jeff KingFeb 7, 2024
  21. Patrick SteinhardtFeb 8, 2024
  22. Jeff KingFeb 15, 2024
  23. 2/2 ci: add jobs to test with the reftable backendPatrick Steinhardt, Feb 7, 2024

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.