From: Patrick Steinhardt Date: Fri, 31 Oct 2025 06:42:14 GMT Subject: Re: What's cooking in git.git (Oct 2025, #12; Thu, 30) Message-ID: In-Reply-To: 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: 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