Thread (1 message) 1 message, 1 author, 2026-02-06

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

From: Junio C Hamano <hidden>
Date: 2026-02-06 19:37:26

Patrick Steinhardt [off-list ref] writes:
quoted
* 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: [ref]
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.
quoted
* 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. [ref]
 source: [ref]
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 [ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help