Re: What's cooking in git.git (Aug 2026, #10)

[Patrick Steinhardt <ps@pks.im>]

On Mon, Aug 24, 2026 at 06:01:10AM -0700, Junio C Hamano wrote:
> * ps/odb-geometric-repack-loose-threshold (2026-08-11) 1 commit
>  - odb/files: be less aggressive with geometric repacking
> 
>  The threshold for geometric repacking to trigger based on loose
>  object count has been adjusted to match that of 'git gc --auto',
>  preventing over-aggressive repacking during concurrent writes.
> 
>  Will merge to 'next'?
>  cf. <aoTcxJSmKWNhnjZ9@denethor>
>  cf. <CABPp-BHgyVTHB_OGmCL4JprFFe6_MapOQNSjUOhJxu-+oWbErg@mail.gmail.com>
>  source: <20260811-pks-geometric-maintenance-reduce-frequency-v1-1-7a54c42355ac@pks.im>

Yeah, this series can be merged.

> * fr/pack-objects-trace-pack-bytes (2026-08-19) 1 commit
>  - pack-objects: trace pack bytes written
> 
>  The pack-objects command has been updated to record the total bytes
>  written to pack files in trace2 output, allowing performance
>  analysis of different compression settings by comparing the
>  resulting pack sizes.
> 
>  Needs review.
>  cf. <aobFLJuiuM1EuNpv@pks.im>
>  cf. <20260820082102.GA2973952@coredump.intra.peff.net>
>  source: <c6a8cdac36d2202055d637ebcc97e484122cdcd4.1787158152.git.friel@openai.com>

I mentioned in my review that we might want to use a different hash
algorithm, but I think the ultimately patch is fine as-is. And both Peff
and you also acked it.

> * ps/odb-pluggable-pack-generation (2026-08-20) 6 commits
>  - bundle: generate packfiles via the object database
>  - bundle: get (mostly) rid of `the_repository`
>  - builtin/bundle: refactor option handling for progress meter
>  - send-pack: generate packfiles via the object database
>  - upload-pack: generate packfiles via the object database
>  - odb: introduce interface to generate packfiles
> 
>  The mechanism to generate a packfile corresponding to the result of
>  a fetch/push has been made pluggable through a set of object
>  database callback functions, removing hardcoded references to
>  'pack-objects' and enabling alternative ODBs to serve packfiles
>  themselves.
> 
>  Will merge to 'next'?
>  cf. <CABPp-BHAeb5Q6kWw8e0fz9+avKyJL0_k7cUzRhesHScJjB3Xfw@mail.gmail.com>
>  cf. <CAOLa=ZQMjb1SzYTVVuMF0ajmre_5_q=L6bmSQwYY233f-RiVXA@mail.gmail.com>
>  source: <20260821-b4-pks-odb-generate-pack-v4-0-074e8bd641f8@pks.im>

Yeah, I think this series should be ready.

> * jt/receive-pack-pluggable-writes (2026-08-20) 9 commits
>  - odb/transaction: add transaction interface to write packfiles
>  - odb: return temporary ODB source when set
>  - builtin/receive-pack: explicitly pass packfile fd
>  - builtin/receive-pack: report unpack errors via strbuf
>  - builtin/receive-pack: lift global state out of unpack()
>  - builtin/receive-pack: read unpack limit config lazily
>  - builtin/receive-pack: pass shallow file explicitly
>  - odb/transaction: add transaction finalize interface
>  - builtin/receive-pack: properly clean up keep files
> 
>  The 'git receive-pack' command has been updated to use a new ODB
>  transaction interface for writing incoming packfiles, making it more
>  backend-agnostic.
> 
>  Will merge to 'next'?
>  cf. <aohD54ZQEyybw008@pks.im>
>  cf. <xmqqo6evqzsu.fsf@gitster.g>
>  source: <20260820234940.894624-1-jltobler@gmail.com>

I'm happy with the state of this series.

> * ps/odb-eagerly-load-alternates (2026-08-17) 6 commits
>  - odb: drop `alternates_db` field
>  - odb: drop `loaded_alternates` field
>  - odb: eagerly initialize alternates
>  - odb: decouple source path comparisons from `the_repository`
>  - setup: create ref and object databases after config is written
>  - Merge branch 'ps/odb-make-creation-pluggable' into ps/odb-eagerly-load-alternates
> 
>  The object database layer has been simplified by eagerly loading
>  alternate object directories upon initialization, instead of
>  deferring it to the first object lookup.  This eliminates the need
>  for scattered lazy-loading calls throughout the codebase and paves
>  the way for integrating alternates with the pluggable backends.
> 
>  Will merge to 'next'?
>  cf. <CAOLa=ZReodSXjEbQkFoxcofMLq6mUOjXANRg7bZ2uEKKQn=DXw@mail.gmail.com>
>  cf. <xmqqik53qz5j.fsf@gitster.g>
>  source: <20260817-pks-odb-eagerly-prepare-alternates-v3-0-1115a7e02467@pks.im>

Yup, I think the discussion around "core.ignoreCase" has wound down by
now and we seem to all be on the same page there. I don't think any
further changes should be necessary as a result of it.

> * vm/complete-history (2026-08-13) 4 commits
>  - completion: complete 'git history split' pathspecs
>  - completion: complete 'git history --update-refs' values
>  - completion: complete 'git history --empty' values
>  - completion: add 'git history' subcommands
> 
>  The command line completion (in contrib/) has been taught to handle
>  the experimental 'git history' command.
> 
>  Will merge to 'next'?
>  cf. <aoWP3TYq5rNjUx7S@pks.im>
>  cf. <xmqqse49uanx.fsf@gitster.g>
>  source: <20260813-history_autocompletion-v3-0-69eed1cea93a@kernel.org>

I'm happy with this version.

> * dk/use-nsec-runtime (2026-08-20) 3 commits
>  - core: convert build-time USE_NSEC into runtime core.useNanosec
>  - environment: align repo_config_values_init with struct declaration
>  - meson: expose knob for xmlto relative links in manuals
> 
>  The build-time knob 'USE_NSEC' for nanosecond stat precision has been
>  converted to a runtime configuration 'core.useNanosec', allowing
>  distributions to bundle one binary that adapts to filesystem
>  capabilities dynamically.
> 
>  Needs review.
>  cf. <xmqqa4qgsn20.fsf@gitster.g>
>  cf. <aoaP7oIrR_Bpvx34@pks.im>
>  source: <cover.1787231825.git.ben.knoble@gmail.com>

I haven't gotten around to it yet, but will try to review it tomorrow.

Thanks!

Patrick