Re: What's cooking in git.git (Nov 2024, #10; Thu, 28)

[Patrick Steinhardt <ps@pks.im>]

> * ps/reftable-iterator-reuse (2024-11-26) 11 commits
>  - refs/reftable: reuse iterators when reading refs
>  - reftable/merged: drain priority queue on reseek
>  - reftable/stack: add mechanism to notify callers on reload
>  - refs/reftable: refactor reflog expiry to use reftable backend
>  - refs/reftable: refactor reading symbolic refs to use reftable backend
>  - refs/reftable: read references via `struct reftable_backend`
>  - refs/reftable: figure out hash via `reftable_stack`
>  - reftable/stack: add accessor for the hash ID
>  - refs/reftable: handle reloading stacks in the reftable backend
>  - refs/reftable: encapsulate reftable stack
>  - Merge branch 'ps/reftable-detach' into ps/reftable-iterator-reuse
>  (this branch uses ps/reftable-detach.)
> 
>  Optimize reading random references out of the reftable backend by
>  allowing reuse of iterator objects.
> 
>  Will merge to 'next'?
>  source: <20241126-pks-reftable-backend-reuse-iter-v4-0-b17fd27df126@pks.im>

I think this series should be ready, but...

> * ps/reftable-detach (2024-11-19) 8 commits
>  - reftable/system: provide thin wrapper for lockfile subsystem
>  - reftable/stack: drop only use of `get_locked_file_path()`
>  - reftable/system: provide thin wrapper for tempfile subsystem
>  - reftable/stack: stop using `fsync_component()` directly
>  - reftable/system: stop depending on "hash.h"
>  - reftable: explicitly handle hash format IDs
>  - reftable/system: move "dir.h" to its only user
>  - Merge branch 'ps/reftable-strbuf' into ps/reftable-detach
>  (this branch is used by ps/reftable-iterator-reuse.)
> 
>  Isolates the reftable subsystem from the rest of Git's codebase by
>  using fewer pieces of Git's infrastructure.
> 
>  Needs review.
>  source: <cover.1731943954.git.ps@pks.im>

... it depends on this series here. From my point of view it is ready,
as well, and has gotten a favorable review by Karthik. So I wouldn't
mind if we merged both series to `next` together.

> * ps/build (2024-11-26) 24 commits
>  - meson: fix conflicts with in-flight topics
>  - Introduce support for the Meson build system
>  - Documentation: add comparison of build systems
>  - t: allow overriding build dir
>  - t: better support for out-of-tree builds
>  - Documentation: extract script to generate a list of mergetools
>  - Documentation: teach "cmd-list.perl" about out-of-tree builds
>  - Documentation: allow sourcing generated includes from separate dir
>  - Makefile: simplify building of templates
>  - Makefile: allow "bin-wrappers/" directory to exist
>  - Makefile: refactor generators to be PWD-independent
>  - Makefile: extract script to generate gitweb.js
>  - Makefile: extract script to generate gitweb.cgi
>  - Makefile: extract script to massage Shell scripts
>  - Makefile: use "generate-perl.sh" to massage Perl library
>  - Makefile: extract script to massage Perl scripts
>  - Makefile: consistently use PERL_PATH
>  - Makefile: generate doc versions via GIT-VERSION-GEN
>  - Makefile: generate "git.rc" via GIT-VERSION-GEN
>  - Makefile: propagate Git version via generated header
>  - Makefile: refactor GIT-VERSION-GEN to be reusable
>  - Makefile: consistently use @PLACEHOLDER@ to substitute
>  - Makefile: use common template for GIT-BUILD-OPTIONS
>  - Merge branch 'ps/clar-build-improvement' into ps/build
> 
>  Build procedure update plus introduction of Mason based builds
> 
>  Will merge to 'next'?
>  source: <20241125-pks-meson-v9-0-1c6cf242a5f1@pks.im>

I've got two small fixes pending, but other than I think the series is
in a good enough shape for a first iteration. There's of coure a couple
of follow-up steps that I plan to do, like wiring up CI, but I think
it's fine to do these in a separate series.

I'll send this version out in a bit. If you decide to merge, please
note that the tip of the branch is only for compatibility with "seen"
and should not be merged to "next".

Patrick