Taylor Blau <me@xxxxxxxxxxxx> wrote: > I'm not sure if I remember why `table[i] - selected->xor_offset` is > right and not `i - selected->xor_offset`. 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 :)
