From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/7] pack-bitmap: iterate object sources when opening bitmaps
Date: Thu, 9 Jul 2026 16:08:31 -0500 [thread overview]
Message-ID: <alADU8qRZcPB0Zcv@denethor> (raw)
In-Reply-To: <20260709-pks-odb-for-each-object-filter-v1-4-82fe014b12b3@pks.im>
On 26/07/09 10:35AM, Patrick Steinhardt wrote:
> When opening a bitmap for a repository we perform two steps:
>
> - We first look for a multi-pack index bitmap in any of the object
> sources connected to the repository.
>
> - We then look for a packfile bitmap in any of the packfiles of any of
> the object sources.
So IIUC, we generally stop searching for a bitmap once we find one.
> Both of these steps thus iterate through object sources themselves, one
> via `odb_prepare_alternates()` and one via `repo_for_each_pack()`. This
> layout makes it hard to introduce a way to open the bitmap of one
> specific object source, which is functionality that we'll require in a
> subsequent commit.
>
> Reverse the loop so that we instead loop through all sources in the
> outer loop, and then for each source we try to load its bitmap via
> either the multi-pack index or via a packfile.
Conceptually, I think this is a lot easier to follow too which is nice.
> Note that this changes the precedence of bitmaps in one specific edge
> case: when an earlier object source only has a packfile bitmap, but a
> later source has a multi-pack index bitmap, we now pick the packfile
> bitmap of the earlier source. Previously, a multi-pack index bitmap from
> any source would have taken precedence over all packfile bitmaps. Given
> that object sources are ordered such that the local source comes first,
> this arguably is an improvement, as we now prefer local bitmaps over
> bitmaps in alternates. Furthermore, we already warn about repositories
> that have multiple bitmaps, so this setup is broken and thus arguably
> not worth worrying about too much.
I agree that the change in bitmap precedent is probably not a big deal.
Having multiple bitmaps in a repository is already something we warn
against so I think this should be fine.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> pack-bitmap.c | 65 ++++++++++++++++++++++++++---------------------------------
> 1 file changed, 29 insertions(+), 36 deletions(-)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index eda38a5433..0e3e18a557 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -680,60 +680,53 @@ static int load_bitmap(struct repository *r, struct bitmap_index *bitmap_git,
> return 0;
> }
>
> -static int open_pack_bitmap(struct repository *r,
> - struct bitmap_index *bitmap_git)
> +static int open_bitmap_for_source(struct odb_source_packed *source,
> + struct bitmap_index *bitmap_git)
> {
> - struct packed_git *p;
> + struct multi_pack_index *midx = get_multi_pack_index(source);
> + struct packfile_list_entry *e;
> int ret = -1;
>
> - repo_for_each_pack(r, p) {
> - if (open_pack_bitmap_1(bitmap_git, p) == 0) {
> - ret = 0;
> - /*
> - * The only reason to keep looking is to report
> - * duplicates.
> - */
> - if (!trace2_is_enabled())
> - break;
> - }
> + if (midx && !open_midx_bitmap_1(bitmap_git, midx))
> + ret = 0;
Ok, open_midx_bitmap_1() returns 0 if it find a MIDX and -1 otherwise.
Probably just a matter of preference, but I think writing out like below
is a little bit easier on the eyes:
if (midx)
ret = open_midx_bitmap_1(bitmap_git, midx);
it might just be that I find the return values a bit confusing though.
Maybe we could instead use `found` like a bit later in this patch.
> +
> + for (e = packfile_store_get_packs(source); e; e = e->next) {
> + /*
> + * When tracing is enabled we want to keep looking to report
> + * duplicates even if we have already found a bitmap.
> + */
> + if (!ret && !trace2_is_enabled())
> + break;
So if have already found a bitmap from the MIDX and tracing is not
enabled, we don't continue searching for bitmaps in this source.
> +
> + if (open_pack_bitmap_1(bitmap_git, e->pack))
> + continue;
> + ret = 0;
> }
>
> return ret;
> }
>
> -static int open_midx_bitmap(struct repository *r,
> - struct bitmap_index *bitmap_git)
> +static int open_bitmap(struct repository *r,
> + struct bitmap_index *bitmap_git)
> {
> struct odb_source *source;
> - int ret = -1;
> + int found = 0;
>
> assert(!bitmap_git->map);
>
> odb_prepare_alternates(r->objects);
> for (source = r->objects->sources; source; source = source->next) {
> struct odb_source_files *files = odb_source_files_downcast(source);
> - struct multi_pack_index *midx = get_multi_pack_index(files->packed);
> - if (midx && !open_midx_bitmap_1(bitmap_git, midx))
> - ret = 0;
> - }
> - return ret;
> -}
> -
> -static int open_bitmap(struct repository *r,
> - struct bitmap_index *bitmap_git)
> -{
> - int found;
>
> - assert(!bitmap_git->map);
> + found |= !open_bitmap_for_source(files->packed, bitmap_git);
>
> - found = !open_midx_bitmap(r, bitmap_git);
> -
> - /*
> - * these will all be skipped if we opened a midx bitmap; but run it
> - * anyway if tracing is enabled to report the duplicates
> - */
> - if (!found || trace2_is_enabled())
> - found |= !open_pack_bitmap(r, bitmap_git);
> + /*
> + * The only reason to keep looking after having found a bitmap
> + * is to report duplicates.
> + */
> + if (found && !trace2_is_enabled())
> + break;
> + }
Ok, we only advance to the next source if tracing is enabled to print
warnings for multiple bitmaps. Makes sense.
Overall I quite like the direction of this patch.
-Justin
next prev parent reply other threads:[~2026-07-09 21:08 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 8:35 [PATCH 0/7] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 1/7] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-09 19:54 ` Justin Tobler
2026-07-10 7:08 ` Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 2/7] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 3/7] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-09 20:19 ` Justin Tobler
2026-07-10 7:08 ` Patrick Steinhardt
2026-07-11 7:47 ` Jeff King
2026-07-09 8:35 ` [PATCH 4/7] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-09 21:08 ` Justin Tobler [this message]
2026-07-10 7:08 ` Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 5/7] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 6/7] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-09 21:43 ` Justin Tobler
2026-07-10 7:09 ` Patrick Steinhardt
2026-07-09 8:35 ` [PATCH 7/7] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-09 18:59 ` Junio C Hamano
2026-07-10 7:09 ` Patrick Steinhardt
2026-07-10 8:48 ` [PATCH v2 0/8] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-10 8:48 ` [PATCH v2 1/8] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-10 22:25 ` Taylor Blau
2026-07-13 9:54 ` Patrick Steinhardt
2026-07-14 3:49 ` Taylor Blau
2026-07-14 5:35 ` Patrick Steinhardt
2026-07-10 8:48 ` [PATCH v2 2/8] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-10 22:25 ` Taylor Blau
2026-07-10 8:48 ` [PATCH v2 3/8] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-10 22:34 ` Taylor Blau
2026-07-11 8:01 ` Jeff King
2026-07-13 9:53 ` Patrick Steinhardt
2026-07-14 3:58 ` Taylor Blau
2026-07-14 7:17 ` Jeff King
2026-07-10 8:48 ` [PATCH v2 4/8] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-10 22:40 ` Taylor Blau
2026-07-10 8:48 ` [PATCH v2 5/8] pack-bitmap: drop `_1` suffix from functions that open bitmaps Patrick Steinhardt
2026-07-10 22:41 ` Taylor Blau
2026-07-10 8:48 ` [PATCH v2 6/8] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-10 8:48 ` [PATCH v2 7/8] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-10 22:42 ` Taylor Blau
2026-07-10 8:49 ` [PATCH v2 8/8] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-11 7:58 ` [PATCH v2 9/8?] pack-objects: drop unused return value from add_object_entry() Jeff King
2026-07-11 16:42 ` Junio C Hamano
2026-07-13 14:41 ` [PATCH v3 0/9] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 1/9] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 2/9] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 3/9] pack-objects: drop unused return value from add_object_entry() Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 4/9] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 5/9] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 6/9] pack-bitmap: drop `_1` suffix from functions that open bitmaps Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 7/9] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 8/9] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-13 14:41 ` [PATCH v3 9/9] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-14 3:59 ` [PATCH v3 0/9] odb: introduce object filters to `odb_for_each_object()` Taylor Blau
2026-07-14 5:36 ` Patrick Steinhardt
2026-07-14 7:17 ` Jeff King
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=alADU8qRZcPB0Zcv@denethor \
--to=jltobler@gmail.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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