Re: [PATCH 3/6] pack-bitmap-write.c: write lookup table extension

Taylor Blau <me@ttaylorr.com> wrote:

Even I myself got confused! Before sending the patch to the mailing list, I was clear about that. That's why I didn't catch the so called mistake I have been notifying till now. Thanks Taylor for asking the question!

I should add a comment before the line so that people can understand it. Let us parse `table_inv[table[i] - selected->xor_offset]` -

Suppose bitmap entries be like - 

Bitmap 0 (for commit 0) Bitmap 1 (for commit 1) Bitmap 2 (for commit 2) Bitmap 3 (for commit 3) . . . Bitmap 20 (for commit 20)

These bitmaps are ordered by the date of their corresponding commit. `table` array maps commit's lexicographic order to its bitmap order. `table_inv` stores the reverse (i.e. it maps bitmap order to lexicographic order). Say for example, if commit 4 is lexicographically first among all the Commits then `table[0]` is 4. Similarly `table[1]`=2, table[2]=1 etc. `table_inv[4]` is 0, table_inv[2]=1 etc.

Now suppose commit 4's bitmap has xor-relation with commit 2's bitmap. So, xor-offset for bitmap 4 is 2. And `table[0] - selected->xor_offset` is equal to 4-2 = 2. It is pointing to the commit 2. Now, 2 is in bitmap Order. We need to convert it into lexicographic order. So, table_inv[2] gives us the lexicographic order position of commit 2 I.e. 1.

Long story short, there is no issue regarding xor_offset. This xor_offset is not relative to the current commit. It is absolute.

Sorry for the initial claim :)