Re: [PATCH 2/3] pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2026, 16:52 UTC
Message-ID: <xmqq7bt0cqec.fsf@gitster.g>
In-Reply-To: <aXrGfGUJQ34JAmuz@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

> Looking at the implementation of bitmap_writer_select_commits(), we do
> not guarantee that *any* reference specified by pack.preferBitmapTips
> will receive a bitmap. That's because we don't necessarily enumerate the
> entire set of commits when determining which ones to bitmap.

Hmph.  Is this documented?

	... Goes and looks ...

Yes, it is documented. We say "This is because ..." but it just explains it as what the chosen design of the implementation happens to do, without saying for what benefit the implementation was chosen, so it is unclear if this is designed behaviour, or more importantly, even if this were designed, what the rationale of choosing that design was.

"When they are so close to fall into the same chunk, there is no point having bitmaps individually for them, as their bitmaps will be very similar anyway, so this design saves space without sacrificing the quality of the resulting set of bitmaps" or something?

> At the very least, if we do end up going in this direction (and I am not
> necessarily advocating that we do, since I would prefer a more
> consistent set of behavior), we should at minimum document it in
> git-config(1).

The documentation says "... reference that is a suffix of any value of this configuration". Is "refs/heads/foobar" a "suffix" of "refs/heads/foo"? I actually find this phrasing fairly strange, as I do not think of "refs/heads/main" be a "suffix" of "refs/heads/".