git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Patrick Steinhardt <ps@pks.im>
Date
Oct 31, 2025, 06:42 UTC
Message-ID
<aQRaRuBtt_r7SamL@pks.im>
In-Reply-To
<xmqqpla43wcp.fsf@gitster.g>
On Thu, Oct 30, 2025 at 02:36:54PM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> * 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.

Show 13 quoted lines
> * 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.

Show 8 quoted lines
> * 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?

Show 25 quoted lines
> * 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.
Show 7 quoted lines
> * 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 2 of 10 in “What's cooking in git.git (Oct 2025, #12; Thu, 30)”
  1. Junio C HamanoOct 30, 2025
  2. Patrick SteinhardtOct 31, 2025
  3. Junio C HamanoOct 31, 2025
  4. Eric SunshineOct 31, 2025
  5. Lucas Seiki OshiroNov 3, 2025
  6. Junio C HamanoNov 3, 2025
  7. Junio C HamanoNov 3, 2025
  8. Junio C HamanoNov 3, 2025
  9. Jeff KingNov 3, 2025
  10. Patrick SteinhardtNov 4, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.