git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 4/6] pack-bitmap: prepare to read lookup table extension

From
Taylor Blau <me@ttaylorr.com>
Date
Jun 27, 2022, 21:38 UTC
Message-ID
<YrojV5aYCzxXlV3c@nand.local>
In-Reply-To
<4fbfcff8a208798146cd561b0185e094a116cf0e.1656249017.git.gitgitgadget@gmail.com>
On Sun, Jun 26, 2022 at 01:10:15PM +0000, Abhradeep Chakraborty via GitGitGadget wrote:
Show 7 quoted lines
> From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
>
> Earlier change teaches Git to write bitmap lookup table. But Git
> does not know how to parse them.
>
> Teach Git to parse the existing bitmap lookup table. The older
> versions of git are not affected by it. Those versions ignore the
s/git/Git
Show 22 quoted lines
> lookup table.
>
> Signed-off-by: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
> Mentored-by: Taylor Blau <me@ttaylorr.com>
> Co-Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> ---
>  pack-bitmap.c                 | 193 ++++++++++++++++++++++++++++++++--
>  t/t5310-pack-bitmaps.sh       |   7 ++
>  t/t5326-multi-pack-bitmaps.sh |   1 +
>  3 files changed, 191 insertions(+), 10 deletions(-)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index 36134222d7a..9e09c5824fc 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -82,6 +82,12 @@ struct bitmap_index {
>  	/* The checksum of the packfile or MIDX; points into map. */
>  	const unsigned char *checksum;
>
> +	/*
> +	 * If not NULL, this point into the commit table extension
> +	 * (within map).

It may be worth replacing "within map" to "within the memory mapped region `map`" to make clear that this points somewhere within the mmap.

> +	 */
> +	unsigned char *table_lookup;
> +
Show 7 quoted lines
> @@ -185,6 +191,22 @@ static int load_bitmap_header(struct bitmap_index *index)
>  			index->hashes = (void *)(index_end - cache_size);
>  			index_end -= cache_size;
>  		}
> +
> +		if (flags & BITMAP_OPT_LOOKUP_TABLE &&
> +			git_env_bool("GIT_TEST_READ_COMMIT_TABLE", 1)) {

I should have commented on this in an earlier round, but I wonder what the behavior should be when we have BITMAP_OPT_LOOKUP_TABLE in our flags, but GIT_TEST_READ_COMMIT_TABLE is disabled.

Right now, it doesn't matter, since there aren't any flags in bits above BITMAP_OPT_LOOKUP_TABLE. But in the future, if there was some BITMAP_OPT_FOO that was newer than BITMAP_OPT_LOOKUP_TABLE, we would want to be able to read it without needing to read the lookup table.

At least, I think that should be true, though I would be interested to hear if anybody has a differing opinion there.

> +			size_t table_size = 0;
> +			size_t triplet_sz = st_add3(sizeof(uint32_t),    /* commit position */
> +							sizeof(uint64_t),    /* offset */
> +							sizeof(uint32_t));    /* xor offset */

I don't think we need a st_add3() call here, since the size of these three types is known to be small and thus won't overflow the available range of size_t.

> +			table_size = st_add(table_size,
> +					st_mult(ntohl(header->entry_count),
> +						triplet_sz));

And table_size here is going to start off at zero, so the outer st_add() call isn't necessary, either. This should instead be:

    size_t table_size = st_mult(ntohl(header->entry_count),
                                sizeof(uint32_t) + sizeof(uint64_t) + sizeof(uint32_t));

It might be nice to have triplet_sz #define'd somewhere else, since there are a handful of declarations in this patch that are all identical. Probably something like:

    #define BITMAP_LOOKUP_TABLE_RECORD_WIDTH (sizeof(uint32_t) + sizeof(uint64_t) + sizeof(uin32_t))
or even:
    /*
     * The width in bytes of a single record in the lookup table
     * extension:
     *
     *   (commit_pos, offset, xor_pos)
     *
     * whose fields are 32-, 64-, and 32-bits wide, respectively.
     */
    #define BITMAP_LOOKUP_TABLE_RECORD_WIDTH (16)
> +			if (table_size > index_end - index->map - header_size)
> +				return error("corrupted bitmap index file (too short to fit lookup table)");

if we decide to still recognize the lookup table extension without *reading* from it when GIT_TEST_READ_COMMIT_TABLE is unset, I think we should do something like:

    if (git_env_bool("GIT_TEST_READ_COMMIT_TABLE", 1))
        index->table_lookup = (void *)(index_end - table_size);
    index_end -= table_size;
...where the subtraction on index_end happens unconditionally.
> +static inline const void *bitmap_get_triplet(struct bitmap_index *bitmap_git, uint32_t xor_pos)
> +{
> +	size_t triplet_sz = st_add3(sizeof(uint32_t), sizeof(uint64_t), sizeof(uint32_t));
Same note about the #define constant here.
> +	const void *p = bitmap_git->table_lookup + st_mult(xor_pos, triplet_sz);
And this can be returned directly. Just:
    return bitmap_git->table_lookup + st_mult(xor_pos, BITMAP_LOOKUP_TABLE_RECORD_WIDTH);
although I wonder: why "xor_pos" and not just "pos" here?
Show 11 quoted lines
> +static uint64_t triplet_get_offset(const void *triplet)
> +{
> +	const void *p = (unsigned char*) triplet + sizeof(uint32_t);
> +	return get_be64(p);
> +}
> +
> +static uint32_t triplet_get_xor_pos(const void *triplet)
> +{
> +	const void *p = (unsigned char*) triplet + st_add(sizeof(uint32_t), sizeof(uint64_t));
> +	return get_be32(p);
> +}

I wonder if we could get rid of these functions altogether and return a small structure like:

    struct bitmap_lookup_table_record {
        uint32_t commit_pos;
        uint64_t offset;
        uint32_t xor_pos;
    };
or similar.
Show 5 quoted lines
> +static int triplet_cmp(const void *va, const void *vb)
> +{
> +	int result = 0;
> +	uint32_t *a = (uint32_t *) va;
> +	uint32_t b = get_be32(vb);

Hmm. This is a little tricky to read. Here we're expecting "va" to hold commit_pos from below, and "vb" to be a pointer at a lookup record. Everything here is right, though I wonder if a comment or two might clarify why one is "*(uint32_t *)va" and the other is "get_be32(vb)".

Show 6 quoted lines
> +	if (*a > b)
> +		result = 1;
> +	else if (*a < b)
> +		result = -1;
> +	else
> +		result = 0;

Let's just return the result of the comparison directly here. And while I'm looking at it, I think we can avoid dereferencing "a" on each use, and instead just dereference va on assignment after casting, e.g.:

    uint32_t a = *(uint32_t*)va;
Show 6 quoted lines
> +static uint32_t bsearch_pos(struct bitmap_index *bitmap_git, struct object_id *oid,
> +						uint32_t *result)
> +{
> +	int found;
> +
> +	if (bitmap_git->midx)
Nit: let's use the bitmap_is_midx() helper here instead of looking at
bitamp_git->midx directly.
Show 6 quoted lines
> +		found = bsearch_midx(oid, bitmap_git->midx, result);
> +	else
> +		found = bsearch_pack(oid, bitmap_git->pack, result);
> +
> +	return found;
> +}
Makes sense.
Show 21 quoted lines
> +static struct stored_bitmap *lazy_bitmap_for_commit(struct bitmap_index *bitmap_git,
> +					  struct commit *commit)
> +{
> +	uint32_t commit_pos, xor_pos;
> +	uint64_t offset;
> +	int flags;
> +	const void *triplet = NULL;
> +	struct object_id *oid = &commit->object.oid;
> +	struct ewah_bitmap *bitmap;
> +	struct stored_bitmap *xor_bitmap = NULL;
> +	size_t triplet_sz = st_add3(sizeof(uint32_t), sizeof(uint64_t), sizeof(uint32_t));
> +
> +	int found = bsearch_pos(bitmap_git, oid, &commit_pos);
> +
> +	if (!found)
> +		return NULL;
> +
> +	triplet = bsearch(&commit_pos, bitmap_git->table_lookup, bitmap_git->entry_count,
> +						triplet_sz, triplet_cmp);
> +	if (!triplet)
> +		return NULL;

OK. If you don't mind, I'm going to "think aloud" while I read through this function to make sure that we're on the same page.

First thing is to convert the commit OID we're looking for into its position within the corresponding pack index or MIDX file so that we can use it as a search key to locate in the lookup table. If we didn't find anything, or the commit doesn't exist in our pack / MIDX, nothing to do.

> +
> +	offset = triplet_get_offset(triplet);
> +	xor_pos = triplet_get_xor_pos(triplet);
Otherwise, record its offset and XOR "offset".
Show 9 quoted lines
> +
> +	if (xor_pos != 0xffffffff) {
> +		int xor_flags;
> +		uint64_t offset_xor;
> +		uint32_t *xor_positions;
> +		struct object_id xor_oid;
> +		size_t size = 0;
> +
> +		ALLOC_ARRAY(xor_positions, bitmap_git->entry_count);

If we are XOR'd with another bitmap, make a stack of those bitmaps so that we can decompress ourself.

I'm a little surprised that we're allocating an array as large as bitmap_git->entry_count. It's not wrong, but it does waste some bytes since we likely don't often have these long chains of XOR'd bitmaps.

We should instead allocate a smaller array and grow it over time (search for examples of ALLOC_GROW() to see the canonical way to do this in Git's codebase).

Show 7 quoted lines
> +		while (xor_pos != 0xffffffff) {
> +			xor_positions[size++] = xor_pos;
> +			triplet = bitmap_get_triplet(bitmap_git, xor_pos);
> +			xor_pos = triplet_get_xor_pos(triplet);
> +		}
> +
> +		while (size){
Nit: missing space after ")" and before "{".
> +			xor_pos = xor_positions[size - 1];
> +			triplet = bitmap_get_triplet(bitmap_git, xor_pos);

We already have to get the triplets in the loop above, and then we dig them back out here. Would it be easier to keep track of a list of pointers into the mmaped region instead of looking up these triplets each time?

> +			commit_pos = get_be32(triplet);
> +			offset_xor = triplet_get_offset(triplet);
> +
> +			if (nth_bitmap_object_oid(bitmap_git, &xor_oid, commit_pos) < 0) {

Should it be an error if we can't look up the object's ID here? I'd think so.

Show 9 quoted lines
> +				free(xor_positions);
> +				return NULL;
> +			}
> +
> +			bitmap_git->map_pos = offset_xor + sizeof(uint32_t) + sizeof(uint8_t);
> +			xor_flags = read_u8(bitmap_git->map, &bitmap_git->map_pos);
> +			bitmap = read_bitmap_1(bitmap_git);
> +
> +			if (!bitmap){
Nit: missing space between ")" and "{".
Show 6 quoted lines
> +				free(xor_positions);
> +				return NULL;
> +			}
> +
> +			xor_bitmap = store_bitmap(bitmap_git, bitmap, &xor_oid, xor_bitmap, xor_flags);
> +			size--;
Makes sense. Nicely done!
Show 8 quoted lines
> +		}
> +
> +		free(xor_positions);
> +	}
> +
> +	bitmap_git->map_pos = offset + sizeof(uint32_t) + sizeof(uint8_t);
> +	flags = read_u8(bitmap_git->map, &bitmap_git->map_pos);
> +	bitmap = read_bitmap_1(bitmap_git);

Great, and now we can finally read the original bitmap that we wanted to...

> +	if (!bitmap)
> +		return NULL;
> +
> +	return store_bitmap(bitmap_git, bitmap, oid, xor_bitmap, flags);

...and XOR it with the thing we built up in the loop. Very nicely done. Do we have a good way to make sure that we're testing this code in CI? It *seems* correct to me, but of course, we should have a computer check that this produces OK results, not a human ;).

Show 15 quoted lines
> +}
> +
>  struct ewah_bitmap *bitmap_for_commit(struct bitmap_index *bitmap_git,
>  				      struct commit *commit)
>  {
>  	khiter_t hash_pos = kh_get_oid_map(bitmap_git->bitmaps,
>  					   commit->object.oid);
> -	if (hash_pos >= kh_end(bitmap_git->bitmaps))
> -		return NULL;
> +	if (hash_pos >= kh_end(bitmap_git->bitmaps)) {
> +		struct stored_bitmap *bitmap = NULL;
> +		if (!bitmap_git->table_lookup)
> +			return NULL;
> +
> +		/* NEEDSWORK: cache misses aren't recorded */

For what it's worth, I think that it's completely fine to leave this as a NEEDSWORK for the purposes of this series. I think we plausibly could improve this in certain scenarios by finding some threshold on cache misses when we should just fault in all bitmaps, but that can easily be done on top.

> +		bitmap = lazy_bitmap_for_commit(bitmap_git, commit);
> +		if(!bitmap)
Nit: missing space between "if" and "(".
Show 18 quoted lines
> +			return NULL;
> +		return lookup_stored_bitmap(bitmap);
> +	}
>  	return lookup_stored_bitmap(kh_value(bitmap_git->bitmaps, hash_pos));
>  }
>
> @@ -1699,9 +1861,13 @@ void test_bitmap_walk(struct rev_info *revs)
>  	if (revs->pending.nr != 1)
>  		die("you must specify exactly one commit to test");
>
> -	fprintf(stderr, "Bitmap v%d test (%d entries loaded)\n",
> +	fprintf(stderr, "Bitmap v%d test (%d entries)\n",
>  		bitmap_git->version, bitmap_git->entry_count);
>
> +	if (!bitmap_git->table_lookup)
> +		fprintf(stderr, "Bitmap v%d test (%d entries loaded)\n",
> +			bitmap_git->version, bitmap_git->entry_count);
> +

I think we should probably print just one or the other here, perhaps like:

    fprintf(stderr, "Bitmap v%d test (%d entries%s)",
            bitmap_git->version,
            bitmap_git->entry_count,
            bitmap_git->table_lookup ? "" : " loaded");
Show 27 quoted lines
>  	root = revs->pending.objects[0].item;
>  	bm = bitmap_for_commit(bitmap_git, (struct commit *)root);
>
> @@ -1753,10 +1919,16 @@ void test_bitmap_walk(struct rev_info *revs)
>
>  int test_bitmap_commits(struct repository *r)
>  {
> -	struct bitmap_index *bitmap_git = prepare_bitmap_git(r);
> +	struct bitmap_index *bitmap_git = NULL;
>  	struct object_id oid;
>  	MAYBE_UNUSED void *value;
>
> +	/* As this function is only used to print bitmap selected
> +	 * commits, we don't have to read the commit table.
> +	 */
> +	setenv("GIT_TEST_READ_COMMIT_TABLE", "0", 1);
> +
> +	bitmap_git = prepare_bitmap_git(r);
>  	if (!bitmap_git)
>  		die("failed to load bitmap indexes");
>
> @@ -1764,6 +1936,7 @@ int test_bitmap_commits(struct repository *r)
>  		printf("%s\n", oid_to_hex(&oid));
>  	});
>
> +	setenv("GIT_TEST_READ_COMMIT_TABLE", "1", 1);
>  	free_bitmap_index(bitmap_git);

Hmm. I'm not sure I follow the purpose of tweaking GIT_TEST_READ_COMMIT_TABLE like this with setenv(). Are we trying to avoid reading the lookup table? If so, why? I'd rather avoid manipulating the environment directly like this, and instead have a function we could call to fault in all of the bitmaps (when a lookup table exists, otherwise do nothing).

Thanks, Taylor

Previous: Abhradeep ChakrabortyNext: Abhradeep Chakraborty
Message 66 of 162 in “[GSoC] bitmap: integrate a lookup table extension to the bitmap format”
  1. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  2. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  3. Derrick StoleeJun 20, 2022
  4. Taylor BlauJun 20, 2022
  5. Abhradeep ChakrabortyJun 21, 2022
  6. Taylor BlauJun 22, 2022
  7. Abhradeep ChakrabortyJun 21, 2022
  8. Taylor BlauJun 20, 2022
  9. Abhradeep ChakrabortyJun 21, 2022
  10. Taylor BlauJun 22, 2022
  11. Abhradeep ChakrabortyJun 22, 2022
  12. Derrick StoleeJun 20, 2022
  13. Abhradeep ChakrabortyJun 21, 2022
  14. Taylor BlauJun 22, 2022
  15. 2/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  16. Derrick StoleeJun 20, 2022
  17. Abhradeep ChakrabortyJun 21, 2022
  18. Taylor BlauJun 20, 2022
  19. Abhradeep ChakrabortyJun 21, 2022
  20. Taylor BlauJun 22, 2022
  21. Abhradeep ChakrabortyJun 22, 2022
  22. Taylor BlauJun 22, 2022
  23. 3/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  24. Taylor BlauJun 20, 2022
  25. Abhradeep ChakrabortyJun 21, 2022
  26. Taylor BlauJun 22, 2022
  27. 5/6 bitmap-commit-table: add tests for the bitmap lookup tableAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  28. Taylor BlauJun 22, 2022
  29. 4/6 builtin/pack-objects.c: learn pack.writeBitmapLookupTableTaylor Blau via GitGitGadget, Jun 20, 2022
  30. Taylor BlauJun 20, 2022
  31. 6/6 bitmap-lookup-table: add performance testsAbhradeep Chakraborty via GitGitGadget, Jun 20, 2022
  32. Taylor BlauJun 22, 2022
  33. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  34. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  35. Derrick StoleeJun 27, 2022
  36. Taylor BlauJun 27, 2022
  37. Abhradeep ChakrabortyJun 27, 2022
  38. 2/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  39. Derrick StoleeJun 27, 2022
  40. Taylor BlauJun 27, 2022
  41. Abhradeep ChakrabortyJun 27, 2022
  42. Taylor BlauJun 27, 2022
  43. Abhradeep ChakrabortyJun 27, 2022
  44. 3/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  45. Derrick StoleeJun 27, 2022
  46. 3/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty, Jun 27, 2022
  47. Taylor BlauJun 27, 2022
  48. Taylor BlauJun 27, 2022
  49. Abhradeep ChakrabortyJun 27, 2022
  50. Taylor BlauJun 29, 2022
  51. 5/6 bitmap-lookup-table: add performance tests for lookup tableAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  52. Taylor BlauJun 27, 2022
  53. Abhradeep ChakrabortyJun 28, 2022
  54. Taylor BlauJun 29, 2022
  55. 6/6 p5310-pack-bitmaps.sh: enable pack.writeReverseIndex for testingAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  56. Taylor BlauJun 27, 2022
  57. Abhradeep ChakrabortyJun 28, 2022
  58. 4/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jun 26, 2022
  59. Derrick StoleeJun 27, 2022
  60. Abhradeep ChakrabortyJun 27, 2022
  61. Derrick StoleeJun 27, 2022
  62. Taylor BlauJun 27, 2022
  63. Abhradeep ChakrabortyJun 28, 2022
  64. Taylor BlauJun 29, 2022
  65. Abhradeep ChakrabortyJun 30, 2022
  66. Taylor BlauJun 27, 2022
  67. Abhradeep ChakrabortyJun 28, 2022
  68. Taylor BlauJun 29, 2022
  69. Taylor BlauJun 29, 2022
  70. Abhradeep ChakrabortyJun 30, 2022
  71. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  72. 2/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  73. Taylor BlauJul 14, 2022
  74. Taylor BlauJul 15, 2022
  75. Abhradeep ChakrabortyJul 15, 2022
  76. Taylor BlauJul 15, 2022
  77. Abhradeep ChakrabortyJul 16, 2022
  78. Taylor BlauJul 26, 2022
  79. Martin ÅgrenJul 18, 2022
  80. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  81. Philip OakleyJul 8, 2022
  82. Abhradeep ChakrabortyJul 9, 2022
  83. Philip OakleyJul 10, 2022
  84. Taylor BlauJul 14, 2022
  85. Philip OakleyJul 15, 2022
  86. Abhradeep ChakrabortyJul 15, 2022
  87. 3/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  88. 4/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  89. Taylor BlauJul 15, 2022
  90. Abhradeep ChakrabortyJul 15, 2022
  91. Taylor BlauJul 15, 2022
  92. Martin ÅgrenJul 18, 2022
  93. Abhradeep ChakrabortyJul 18, 2022
  94. Martin ÅgrenJul 18, 2022
  95. Taylor BlauJul 26, 2022
  96. 5/6 bitmap-lookup-table: add performance tests for lookup tableAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  97. Taylor BlauJul 15, 2022
  98. Abhradeep ChakrabortyJul 15, 2022
  99. 6/6 p5310-pack-bitmaps.sh: remove pack.writeReverseIndexAbhradeep Chakraborty via GitGitGadget, Jul 4, 2022
  100. Abhradeep ChakrabortyJul 4, 2022
  101. Junio C HamanoJul 6, 2022
  102. Abhradeep ChakrabortyJul 7, 2022
  103. Kaartic SivaraamJul 7, 2022
  104. Abhradeep ChakrabortyJul 7, 2022
  105. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  106. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  107. 2/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  108. 4/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  109. 5/6 p5310-pack-bitmaps.sh: enable `pack.writeReverseIndex`Abhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  110. 3/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  111. 6/6 bitmap-lookup-table: add performance tests for lookup tableAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  112. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  113. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  114. 2/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  115. Taylor BlauJul 26, 2022
  116. Abhradeep ChakrabortyJul 26, 2022
  117. 4/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  118. Taylor BlauJul 26, 2022
  119. Abhradeep ChakrabortyJul 26, 2022
  120. Eric SunshineJul 26, 2022
  121. 5/6 p5310-pack-bitmaps.sh: enable `pack.writeReverseIndex`Abhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  122. Taylor BlauJul 26, 2022
  123. Ævar Arnfjörð BjarmasonJul 26, 2022
  124. Derrick StoleeJul 26, 2022
  125. Ævar Arnfjörð BjarmasonJul 26, 2022
  126. Abhradeep ChakrabortyJul 26, 2022
  127. 6/6 bitmap-lookup-table: add performance tests for lookup tableAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  128. 3/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty via GitGitGadget, Jul 20, 2022
  129. Johannes SchindelinJul 28, 2022
  130. Abhradeep ChakrabortyAug 2, 2022
  131. Johannes SchindelinAug 2, 2022
  132. Abhradeep ChakrabortyAug 2, 2022
  133. Johannes SchindelinAug 8, 2022
  134. Abhradeep ChakrabortyAug 8, 2022
  135. Johannes SchindelinAug 9, 2022
  136. Abhradeep ChakrabortyAug 9, 2022
  137. Abhradeep ChakrabortyAug 9, 2022
  138. Johannes SchindelinAug 10, 2022
  139. Johannes SchindelinAug 10, 2022
  140. Abhradeep ChakrabortyAug 10, 2022
  141. Derrick StoleeAug 10, 2022
  142. Abhradeep ChakrabortyAug 12, 2022
  143. Derrick StoleeAug 12, 2022
  144. Abhradeep ChakrabortyAug 13, 2022
  145. Taylor BlauAug 16, 2022
  146. Abhradeep ChakrabortyAug 17, 2022
  147. Taylor BlauAug 17, 2022
  148. Taylor BlauAug 19, 2022
  149. Abhradeep ChakrabortyAug 13, 2022
  150. Taylor BlauAug 16, 2022
  151. 0/6 [GSoC] bitmap: integrate a lookup table extension to the bitmap formatAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  152. 2/6 bitmap: move `get commit positions` code to `bitmap_writer_finish`Abhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  153. 1/6 Documentation/technical: describe bitmap lookup table extensionAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  154. 3/6 pack-bitmap-write.c: write lookup table extensionAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  155. 5/6 pack-bitmap: prepare to read lookup table extensionAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  156. 4/6 pack-bitmap-write: learn pack.writeBitmapLookupTable and add testsAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  157. 6/6 bitmap-lookup-table: add performance tests for lookup tableAbhradeep Chakraborty via GitGitGadget, Aug 14, 2022
  158. Junio C HamanoAug 19, 2022
  159. Johannes SchindelinAug 22, 2022
  160. Taylor BlauAug 22, 2022
  161. Taylor BlauAug 25, 2022
  162. Junio C HamanoAug 26, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.