Re: What's cooking in git.git (Sep 2021, #05; Fri, 17)

From: Carlo Arenas <carenas@gmail.com>
Date: Sep 18, 2021, 11:16 UTC
Message-ID: <CAPUEsphMUNYRACmK-nksotP1RrMn09mNGFdEHLLuNEWH4AcU7Q@mail.gmail.com>
In-Reply-To: <xmqqlf3ug3q7.fsf@gitster.g>

Show 8 quoted lines

> * cb/plug-leaks-in-alloca-emu-users (2021-09-16) 2 commits
>   (merged to 'next' on 2021-09-16 at 2eecae2de3)
>  + t0000: avoid masking git exit value through pipes
>  + tree-diff: fix leak when not HAVE_ALLOCA_H
>
>  Leakfix.
>
>  Will merge to 'master'.

Not arguing against, but just to make clear that this is unmasking 4 additional leaks in `git show` that have no fix yet.

So if someone were to run a SANITIZER=leak build it will fail in t0000 while before it will look like it succeeded (at least).

FWIW those leaks don't exist in maint, and while I have brute forced fixes for them, those fixes are not correct and at least one of them might need assistance from dscho who is in PTO.

Show 10 quoted lines

> * cb/pedantic-build-for-developers (2021-09-03) 3 commits
>   (merged to 'next' on 2021-09-10 at b8df102019)
>  + developer: enable pedantic by default
>  + win32: allow building with pedantic mode enabled
>  + gettext: remove optional non-standard parens in N_() definition
>
>  Update the build procedure to use the "-pedantic" build when
>  DEVELOPER makefile macro is in effect.
>
>  Will merge to 'master'.

I was really expecting someone to complain while this was in "next", while there is not much that can be done by cooking it for longer if who would be affected doesn't build "next", I wouldn't be surprised if people complain, so like the previous topic is likely to be "noisy".

Show 7 quoted lines

> * ab/sanitize-leak-ci (2021-09-16) 2 commits
>  - tests: add a test mode for SANITIZE=leak, run it in CI
>  - Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
>
>  CI learns to run the leak sanitizer builds.
>
>  Will merge to 'next'?

This is always failing in "seen", and as explained above will fail also in "next" and "master" which then make it unlikely to be a useful indicator of quality. I think it will be more useful merged into next, if it will only fail there if the guilty topics from "seen" will also get merged, and of course will be even more useful if not failing, but I haven't seen much action there, and as explained above, I am also part of the problem.

Show 26 quoted lines

> * hn/reftable (2021-09-10) 20 commits
>  - fixup! reftable: implement stack, a mutable database of reftable files.
>  - Add "test-tool dump-reftable" command.
>  - reftable: add dump utility
>  - reftable: implement stack, a mutable database of reftable files.
>  - reftable: implement refname validation
>  - reftable: add merged table view
>  - reftable: add a heap-based priority queue for reftable records
>  - reftable: reftable file level tests
>  - reftable: read reftable files
>  - reftable: generic interface to tables
>  - reftable: write reftable files
>  - reftable: a generic binary tree implementation
>  - reftable: reading/writing blocks
>  - Provide zlib's uncompress2 from compat/zlib-compat.c
>  - reftable: (de)serialization for the polymorphic record type.
>  - reftable: add blocksource, an abstraction for random access reads
>  - reftable: utility functions
>  - reftable: add error related functionality
>  - reftable: RFC: add LICENSE
>  - hash.h: provide constants for the hash IDs
>
>  The "reftable" backend for the refs API, without integrating into
>  the refs subsystem.
>
>  Will merge to 'next'?

I reported a minor issue[1] with OpenBSD which AFAIK hasn't been included in a reroll yet There were also concerns about some interfaces being unnecessarily public[0] and code style issues that IMHO might be worth tackling while the series can be replaced wholesale. FWIW this used to be also one of the topics causing the leak CI failures[2]

Carlo

[0] https://lore.kernel.org/git/d3c6bd3d-9f1c-00e3-fa31-67ad0d45fdbf@ramsayjones.plus.com/ [1] https://lore.kernel.org/git/CAPUEspiY=V3y10nc-xUpv7AXwtTv1e1jyRC6FvRrcS3H_ASNnw@mail.gmail.com/ [2] https://lore.kernel.org/git/87sfyfgtfh.fsf@evledraar.gmail.com/