On Wed, Mar 20, 2024 at 06:05:13PM -0400, Taylor Blau wrote: > The pack-bitmap-writer machinery uses a oidmap (backed by khash.h) to > map from commits selected for bitmaps (by OID) to a bitmapped_commit > structure (containing the bitmap itself, among other things like its XOR > offset, etc.) > > This map was initialized at the end of `bitmap_writer_build()`. New > entries are added in `pack-bitmap-write.c::store_selected()`, which is > called by the bitmap_builder machinery (which is responsible for > traversing history and generating the actual bitmaps). > > Reorganize when this field is initialized and when entries are added to > it so that we can quickly determine whether a commit is a candidate for > pseudo-merge selection, or not (since it was already selected to receive > a bitmap, and thus is ineligible for pseudo-merge inclusion). OK, makes sense. I don't think this should violate any assumptions in the current bitmap code (and the sanity checks for duplicate/missing entries in the hash seem right to me). -Peff
