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

From: Junio C Hamano <[email-masked]>
Date: Fri, 06 Feb 2026 11:37:24 -0800

Patrick Steinhardt <[email-masked]> writes:

>> * 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: <[email-masked]>
>
> 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.

After having it in 'seen' for half a month, we haven't seen any new
users to conflict with it, so I am inclined to say we go ahead and
merge it down.

>> * 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. <[email-masked]>
>>  source: <[email-masked]>
>
> 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 <[email-masked]> and subsequent
> messages.

Let me ping the thread.  Taylor asked a bit more time to discuss
mtime related changes a week ago and I do not recall seeing a
further discussion.