Re: What's cooking in git.git (Oct 2025, #12; Thu, 30)

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 30, 2025 at 02:36:54PM -0700, Junio C Hamano wrote:
> * cc/fast-import-export-i18n-cleanup (2025-10-30) 5 commits
>  - gpg-interface: mark a string for translation
>  - fast-import: mark strings for translation
>  - fast-export: mark strings for translation
>  - gpg-interface: use left shift to define GPG_VERIFY_*
>  - gpg-interface: simplify ssh fingerprint parsing
> 
>  Messages from fast-import/export are now marked for i18n.
> 
>  Will merge to 'next'?
>  source: <20251030123332.3337684-1-christian.couder@gmail.com>

I just read through that series. All of the changes look like obvious
improvements to me.

> * ps/packed-git-in-object-store (2025-10-30) 9 commits
>  - packfile: track packs via the MRU list exclusively
>  - packfile: always add packfiles to MRU when adding a pack
>  - packfile: move list of packs into the packfile store
>  - builtin/pack-objects: simplify logic to find kept or nonlocal objects
>  - packfile: fix approximation of object counts
>  - http: refactor subsystem to use `packfile_list`s
>  - packfile: move the MRU list into the packfile store
>  - packfile: use a `strmap` to store packs by name
>  - Merge branch 'ps/remove-packfile-store-get-packs' into ps/packed-git-in-object-store
> 
>  The list of packfiles used in a running Git process is moved from
>  the object-database layer down to object-store layer.

Correction: the list of packfiles is still essentially on the object
database layer. The change here is that it's not contained in `struct
packed_git` anymore, but instead it's moved into the packfile store.
So packfiles become a standalone entity, and the packfile store is
completely responsible for managing the list of packfiles.

>  Will merge to 'next'?
>  source: <20251030-pks-packfiles-store-drop-list-v2-0-84654f080cc0@pks.im>

I think the series is already in a good shape after the last round of
reviews, but let's give reviewers a few more days to reply to the second
version.

> * lo/repo-info-all (2025-10-26) 2 commits
>  - repo: add --all to git-repo-info
>  - repo: factor out field printing to dedicated function
> 
>  "git repo info" learned "--all" option.
> 
>  Will merge to 'next'?
>  source: <20251026225409.46647-1-lucasseikioshiro@gmail.com>

I think there's still a couple of comments from Eric on v3 of this
series that probably need addressing?

> * ps/ref-peeled-tags (2025-10-23) 16 commits
>  - ref-filter: parse objects on demand
>  - ref-filter: detect broken tags when dereferencing them
>  - refs: don't store peeled object IDs for invalid tags
>  - object: add flag to `peel_object()` to verify object type
>  - refs: drop infrastructure to peel via iterators
>  - refs: drop `current_ref_iter` hack
>  - builtin/show-ref: convert to use `reference_get_peeled_oid()`
>  - ref-filter: propagate peeled object ID
>  - upload-pack: convert to use `reference_get_peeled_oid()`
>  - refs: expose peeled object ID via the iterator
>  - refs: refactor reference status flags
>  - refs: fully reset `struct ref_iterator::ref` on iteration
>  - refs: introduce `.ref` field for the base iterator
>  - refs: introduce wrapper struct for `each_ref_fn`
>  - Merge branch 'jt/repo-structure' into ps/ref-peeled-tags
>  - Merge branch 'tb/incremental-midx-part-3.1' into ps/ref-peeled-tags
>  (this branch is used by kn/refs-optim-cleanup; uses jt/repo-structure.)
> 
>  Some ref backend storage can hold not just the object name of an
>  annotated tag, but the object name of the object the tag points at.
>  The code to handle this information has been streamlined.
> 
>  Will merge to 'next' after base topics are merged.
>  source: <20251023-b4-pks-ref-filter-skip-parsing-objects-v4-0-2be68ce82c9a@pks.im>

Both dependencies have landed, so this should be ready to be merged now.

> * je/doc-data-model (2025-10-27) 1 commit
>  - doc: add an explanation of Git's data model
> 
>  Add a new manual that describes the data model.
> 
>  Comments?
>  source: <pull.1981.v4.git.1761593537924.gitgitgadget@gmail.com>

Will have another look at v5 of this series. I think it's nearing a
state where it's good enough to be merged down.

Thanks!

Patrick