Re: What's cooking in git.git (Feb 2026, #02)

From: Patrick Steinhardt <ps@pks.im>
Date: Feb 6, 2026, 16:30 UTC
Message-ID: <aYYXClcfoHT0TZcX@pks.im>
In-Reply-To: <xmqqbji2k6yg.fsf@gitster.g>

On Thu, Feb 05, 2026 at 05:15:51PM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> * jc/ci-test-contrib-too (2026-02-05) 2 commits
>  - ci: avoid ubuntu:rolling in most jobs for now
>  - test: optionally test contrib in CI
> 
>  Test contrib/ things in CI to catch breakages before they enter the
>  "next" branch.
> 
>  Will merge to 'next'?
>  source: <xmqqjywuyhu9.fsf@gitster.g>

I think this is a good first step to fix breakage. We can still iterate on top of it.

Show 13 quoted lines

> * jt/odb-transaction-per-source (2026-02-02) 4 commits
>  - odb: transparently handle common transaction behavior
>  - odb: prepare `struct odb_transaction` to become generic
>  - object-file: rename transaction functions
>  - odb: store ODB source in `struct odb_transaction`
> 
>  Transaction to create objects (or not) is currently tied to the
>  repository, but in the future a repository can have multiple object
>  sources, which may have different transaction mechanisms.  Make the
>  odb transaction API per object source.
> 
>  Comments?
>  source: <20260203001002.2500198-1-jltobler@gmail.com>

This series looks ready to me. There's two comments about the downcast that should use `container_of()` and changes to the tmp_objdir subsystem tto work with `struct odb_source` instead of with the complete repo. But we agreed to handle both of these in follow-up patch series.

Show 11 quoted lines

> * tc/last-modified-not-a-tree (2026-01-30) 4 commits
>  - last-modified: verify revision argument is a commit-ish
>  - last-modified: remove double error message
>  - last-modified: fix memory leak when more than one commit is given
>  - last-modified: rewrite error message when more than one commit given
> 
>  Giving "git last-modified" a tree (not a commit-ish) died an
>  uncontrolled death, which has been corrected.
> 
>  Will merge to 'next'?
>  source: <20260130-toon-last-modified-tree-v6-0-db827e5df985@iotcl.com>

This version looks good to me.

Show 9 quoted lines

> * ps/commit-list-functions-renamed (2026-01-15) 3 commits
>  - commit: rename `free_commit_list()` to conform to coding guidelines
>  - commit: rename `reverse_commit_list()` to conform to coding guidelines
>  - commit: rename `copy_commit_list()` to conform to coding guidelines
> 
>  Rename three functions around the commit_list data structure.
> 
>  Will merge to 'next'?
>  source: <20260115-pks-commit-list-coding-guidelines-v1-0-c58868dbf412@pks.im>

I guess this one depends on the outcome of the discussion we had about renaming stuff. I think it's worth the churn, and don't expect to do another reroll. Otherwise I guess the series can be discarded.

Show 23 quoted lines

> * ps/odb-for-each-object (2026-01-26) 16 commits
>  - odb: drop unused `for_each_{loose,packed}_object()` functions
>  - reachable: convert to use `odb_for_each_object()`
>  - builtin/pack-objects: use `packfile_store_for_each_object()`
>  - odb: introduce mtime fields for object info requests
>  - treewide: drop uses of `for_each_{loose,packed}_object()`
>  - treewide: enumerate promisor objects via `odb_for_each_object()`
>  - builtin/fsck: refactor to use `odb_for_each_object()`
>  - odb: introduce `odb_for_each_object()`
>  - packfile: introduce function to iterate through objects
>  - packfile: extract function to iterate through objects of a store
>  - object-file: introduce function to iterate through objects
>  - object-file: extract function to read object info from path
>  - odb: fix flags parameter to be unsigned
>  - odb: rename `FOR_EACH_OBJECT_*` flags
>  - Merge branch 'ps/packfile-store-in-odb-source' into ps/odb-for-each-object
>  - Merge branch 'ps/read-object-info-improvements' into ps/odb-for-each-object
> 
>  Revamp object enumeration API around odb.
> 
>  Will merge to 'next'?
>  cf. <aXk2FjTUMMThs5Kp@nand.local>
>  source: <20260126-pks-odb-for-each-object-v4-0-5a64a038c791@pks.im>

There's been some discussions around the mtime handling, but I think I've addressed the concerns both with documentation in v4 and with the plans I've layed out in <aXcrftLpfcG4S5AX@pks.im> and subsequent messages.

Show 8 quoted lines

> * pc/lockfile-pid (2026-01-22) 1 commit
>  - lockfile: add PID file for debugging stale locks
> 
>  Allow recording process ID of the process that holds the lock next
>  to a lockfile for diagnosis.
> 
>  Will mrge to 'next'?
>  source: <pull.2011.v6.git.1769109815197.gitgitgadget@gmail.com>

From the ref side of things I'm fine with this series now, and I couldn't come up with any other scenarios where the PID file would cause problems. So I think this is in a good enough state now.

Show 8 quoted lines

> * lo/repo-info-keys (2026-01-23) 2 commits
>  - repo: add new flag --keys to git-repo-info
>  - repo: rename "keyvalue" to "lines"
> 
>  "git repo info" learns "--keys" action to list known keys.
> 
>  Comments?
>  source: <20260123164900.35092-1-lucasseikioshiro@gmail.com>

I expect another reroll of this series with the comments I posted.

Thanks!

Patrick