git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/3] pack-bitmap: deduplicate logic to iterate over preferred bitmap tips

From
Patrick Steinhardt <ps@pks.im>
Date
Jan 30, 2026, 12:58 UTC
Message-ID
<aXyq2_MByjxf3TBX@pks.im>
In-Reply-To
<aXrDD1H4lvBR1sF8@nand.local>
On Wed, Jan 28, 2026 at 09:16:47PM -0500, Taylor Blau wrote:
Show 17 quoted lines
> On Wed, Jan 28, 2026 at 09:49:20AM +0100, Patrick Steinhardt wrote:
> > We have two locations that iterate over the preferred bitmap tips as
> > configured by the user via "pack.preferBitmapTips". Both of these
> > callsites are subtly wrong and can lead to a `BUG()`, which we'll fix in
> > a subsequent commit.
> 
> OK, so there is some bug here that is shared by both call-sites (one in
> the pack-objects case for single-pack bitmaps, and another in the MIDX
> code for multi-pack bitmaps). That bug is yet unspecified, but that
> makes sense since the point of this patch appears to be unifying the two
> implementations together so that both may be fixed at once.
> 
> As of yet, it's not totally clear to me what that bug is having just
> read the cover letter. I don't know how much detail it's worth getting
> into here since you'll end up covering it in much greater detail in the
> following patch, though it might be nice to include at least a taste of
> what's to come beyond just "[they] are subtly wrong".
Sure, can do.
Show 10 quoted lines
> > Prepare for this fix by unifying the two callsites into a new
> > `for_each_preferred_bitmap_tip()` function.
> >
> > This removes the last callsite of `bitmap_preferred_tips()` outside of
> > "pack-bitmap.c". As such, convert the function to be local to that file
> > only.
> 
> OK, I think hiding this implementation from outside of the compilation
> unit makes sense, however I am not sure that we should keep it as a
> separate function.

I originally though the same, but there still is a second callsite of this function. So...

Show 24 quoted lines
> > diff --git a/pack-bitmap.c b/pack-bitmap.c
> > index 972203f12b..2f5cb34009 100644
> > --- a/pack-bitmap.c
> > +++ b/pack-bitmap.c
> > @@ -3323,6 +3323,22 @@ const struct string_list *bitmap_preferred_tips(struct repository *r)
> >  	return NULL;
> >  }
> >
> > +void for_each_preferred_bitmap_tip(struct repository *repo,
> > +				   each_ref_fn cb, void *cb_data)
> > +{
> > +	struct string_list_item *item;
> > +	const struct string_list *preferred_tips;
> > +
> > +	preferred_tips = bitmap_preferred_tips(repo);
> 
> OK, so this is the sole caller of bitmap_preferred_tips() you were
> referring to earlier. That function's implementation is hidden from the
> diff context, but it's effectively a thin wrapper around
> repo_config_get_string_multi().
> 
> I wonder if we should just inline the implementation here into its sole
> caller. Is there a reason to keep them separate? I do not feel strongly
> here, just thinking aloud...

... I actually tried this, only to realize that the function is still called by `bitmap_is_preferred_refname()`, too.

Show 12 quoted lines
> > diff --git a/pack-bitmap.h b/pack-bitmap.h
> > index 1bd7a791e2..d0611d0481 100644
> > --- a/pack-bitmap.h
> > +++ b/pack-bitmap.h
> > @@ -5,6 +5,7 @@
> >  #include "khash.h"
> >  #include "pack.h"
> >  #include "pack-objects.h"
> > +#include "refs.h"
> 
> Oof. I wish that there was a way to forward-declare the each_ref_fn
> type, but there is not AFAIK.

We could get around this by simply open-coding the function signature and having a forward-declaration for `struct reference`. Not sure though whether that's really worth it.

Patrick
Previous: Junio C HamanoNext: Patrick Steinhardt
Message 6 of 42 in “Fix misuse of `refs_for_each_ref_in()`”
  1. 0/3 Fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Jan 28, 2026
  2. 1/3 pack-bitmap: deduplicate logic to iterate over preferred bitmap tipsPatrick Steinhardt, Jan 28, 2026
  3. Karthik NayakJan 28, 2026
  4. Taylor BlauJan 29, 2026
  5. Junio C HamanoJan 29, 2026
  6. Patrick SteinhardtJan 30, 2026
  7. 2/3 pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"Patrick Steinhardt, Jan 28, 2026
  8. Karthik NayakJan 28, 2026
  9. Taylor BlauJan 29, 2026
  10. Junio C HamanoJan 29, 2026
  11. Taylor BlauJan 29, 2026
  12. Junio C HamanoJan 29, 2026
  13. Patrick SteinhardtJan 30, 2026
  14. 3/3 bisect: fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Jan 28, 2026
  15. Jeff KingJan 29, 2026
  16. Junio C HamanoJan 29, 2026
  17. Patrick SteinhardtJan 30, 2026
  18. Karthik NayakJan 28, 2026
  19. 0/4 Fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Jan 30, 2026
  20. 1/4 pack-bitmap: deduplicate logic to iterate over preferred bitmap tipsPatrick Steinhardt, Jan 30, 2026
  21. 2/4 pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"Patrick Steinhardt, Jan 30, 2026
  22. Taylor BlauFeb 2, 2026
  23. Patrick SteinhardtFeb 6, 2026
  24. 3/4 bisect: fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Jan 30, 2026
  25. 4/4 bisect: simplify string_list memory handlingPatrick Steinhardt, Jan 30, 2026
  26. Junio C HamanoJan 30, 2026
  27. Taylor BlauFeb 2, 2026
  28. 0/4 Fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Feb 6, 2026
  29. 1/4 pack-bitmap: deduplicate logic to iterate over preferred bitmap tipsPatrick Steinhardt, Feb 6, 2026
  30. 2/4 pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"Patrick Steinhardt, Feb 6, 2026
  31. Junio C HamanoFeb 6, 2026
  32. 3/4 bisect: fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Feb 6, 2026
  33. 4/4 bisect: simplify string_list memory handlingPatrick Steinhardt, Feb 6, 2026
  34. Taylor BlauFeb 18, 2026
  35. Junio C HamanoFeb 19, 2026
  36. 0/4 Fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Feb 19, 2026
  37. 1/4 pack-bitmap: deduplicate logic to iterate over preferred bitmap tipsPatrick Steinhardt, Feb 19, 2026
  38. 2/4 pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"Patrick Steinhardt, Feb 19, 2026
  39. 3/4 bisect: fix misuse of `refs_for_each_ref_in()`Patrick Steinhardt, Feb 19, 2026
  40. 4/4 bisect: simplify string_list memory handlingPatrick Steinhardt, Feb 19, 2026
  41. Junio C HamanoFeb 26, 2026
  42. Junio C HamanoFeb 26, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.