Git development
 help / color / mirror / Atom feed
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

  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