From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jul 2026, #06)
Date: Wed, 15 Jul 2026 09:15:45 +0200 [thread overview]
Message-ID: <alczoVOVRGl4lJ2B@pks.im> (raw)
In-Reply-To: <xmqqtsq1qfzq.fsf@gitster.g>
On Tue, Jul 14, 2026 at 05:00:09PM -0700, Junio C Hamano wrote:
> * ps/odb-for-each-object-filter (2026-07-13) 10 commits
> - builtin/cat-file: filter objects via object database
> - odb: introduce object filters to `odb_for_each_object()`
> - pack-bitmap: introduce function to open bitmap for a single source
> - pack-bitmap: drop `_1` suffix from functions that open bitmaps
> - pack-bitmap: iterate object sources when opening bitmaps
> - pack-bitmap: allow aborting iteration of bitmapped objects
> - pack-objects: drop unused return value from add_object_entry()
> - pack-bitmap: mark object filter as `const`
> - odb/source-packed: improve lookup when enumerating objects
> - Merge branch 'ps/odb-drop-whence' into ps/odb-for-each-object-filter
> (this branch uses ps/odb-drop-whence.)
>
> The object database enumeration interface 'odb_for_each_object()'
> has been taught to accept object filters, allowing the underlying
> backends to optimize the traversal by using reachability bitmaps
> when available. 'git cat-file --batch-all-objects' has been updated
> to use this generic interface, simplifying its code and avoiding
> direct access to ODB backend internals.
>
> Will merge to 'next'?
> cf. <alW0KzSZuZnHmOZD@com-79390>
> source: <20260713-pks-odb-for-each-object-filter-v3-0-b3c65c641073@pks.im>
I've sent a tiny reroll that fixes two references to function names in
the commit messages. But other than that I think that the latest version
is ready to go.
> * cl/conditional-config-on-worktree-path (2026-07-09) 2 commits
> - config: add "worktree" and "worktree/i" includeIf conditions
> - config: refactor include_by_gitdir() into include_by_path()
>
> The '[includeIf "condition"]' conditional inclusion facility for
> configuration files has been taught to use the location of the
> worktree in its condition.
>
> Will merge to 'next'?
> cf. <alTJCTKR9jOWfgbk@pks.im>
> source: <20260710-includeif-worktree-v8-0-04686d8a616c@black-desk.cn>
I think this one is ready to go, too.
Thanks!
Patrick
prev parent reply other threads:[~2026-07-15 7:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 0:00 What's cooking in git.git (Jul 2026, #06) Junio C Hamano
2026-07-15 7:15 ` Patrick Steinhardt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alczoVOVRGl4lJ2B@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox