Re: [PATCH v2 1/6] Documentation/technical: describe bitmap lookup table extension

From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Date: Jun 27, 2022, 16:51 UTC
Message-ID: <20220627165100.16178-1-chakrabortyabhradeep79@gmail.com>
In-Reply-To: <b2c947c6-b33b-066e-a578-65f769ef4f75@github.com>

Derrick Stolee <derrickstolee@github.com> wrote:

Show 11 quoted lines

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

Show 7 quoted lines

> > +	* {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 :)