On Sat, Aug 17, 2024 at 06:34:01AM -0400, Jeff King wrote: > On Thu, Aug 15, 2024 at 01:31:12PM -0400, Taylor Blau wrote: > > > Ordinarily, the pack-bitmap machinery will select some subset of > > reachable commits to receive bitmaps. But when there are fewer than 100 > > commits indexed in the first place, they will all receive bitmaps as a > > special case. > > > > When this happens, pseudo-merges are not generated, making it impossible > > to test pseudo-merge corner cases with fewer than 100 commits. > > > > Select pseudo-merges even for bitmaps with fewer than 100 commits to > > make such testing easier. In practice, this should not make a difference > > to non-testing bitmaps, as they are unlikely to be used when a > > repository has so few commits to begin with. > > I think you could argue that if there are fewer than 100 commits in the > history that pseudo-merge bitmaps are overkill, so it does not matter > much either way. But I think being consistent with our behavior (i.e., > generating them if asked) is important for testing and debugging. Oh, I think that argument is very fair and makes a lot of sense. The point of this patch wasn't that having pseudo-merge bitmaps for repositories that small (and which already have complete bitmap coverage!) is helpful for performance. Rather, it was to make it easier to test the pseudo-merge code path in small repositories without having to waste CPU cycles to generate 98 extra commits when 2 would do, etc. Thanks, Taylor
