Derrick Stolee <derrickstolee@xxxxxxxxxx> wrote:
> I found this difficult to parse. Here is an attempt at a rewording. Please
> let me know if I misunderstood something when reading your version:
>
> NOTE: The xor_offset stored in the BITMAP_OPT_LOOKUP_TABLE is different
> from the xor_offset used in the bitmap data table. The xor_offset in this
> table indicates the row number within this table of the commit whose
> bitmap is used for the XOR computation with the current commit's stored
> bitmap to create the proper logical reachability bitmap.
>
> This does make me think that "xor_offset" should really be "xor_row" or
> something like that.
Thanks. `xor_row` seems nice to me.
> > + * {empty}
> > + commit pos (4 byte integer, network byte order): ::
> > + It stores the object position of the commit (in the midx or pack index)
> > + to which the i'th bitmap in the bitmap entries belongs.
>
> Ok, we are saving some space here, but relying on looking into the pack-index
> or multi-pack-index to get the actual commit OID.
Seems like I didn't update this particular part. At the time of writing this
patch, I was clear that I would store these triplets in the bitmap's order.
But when I started to implement the "read" part, I realised that these triplets
need to be ordered in ascending order. So I did update the "write extension"
patch but somehow missed this particular part.
Just to be clear, bitmaps are sorted by their commit's date (as far as I know).
Bitmaps for recent commits comes before bitmaps for older commits. So these
two orders are not same. Thus hashmap would not work here.
Will update this portion.
Thanks :)
