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

[Junio C Hamano <gitster@pobox.com>]

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/".