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

* 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.

* 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".

* 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.

* 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/ (local)
[1] https://lore.kernel.org/git/CAPUEspiY=V3y10nc-xUpv7AXwtTv1e1jyRC6FvRrcS3H_ASNnw@mail.gmail.com/ (local)
[2] https://lore.kernel.org/git/87sfyfgtfh.fsf@evledraar.gmail.com/ (local)