From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>, Jeff King <peff@peff.net>,
Junio C Hamano <gitster@pobox.com>,
Patrick Steinhardt <ps@pks.im>
Subject: [PATCH v5 00/14] midx: incremental multi-pack indexes, part two
Date: Thu, 20 Mar 2025 13:56:21 -0400 [thread overview]
Message-ID: <cover.1742493373.git.me@ttaylorr.com> (raw)
In-Reply-To: <cover.1723755667.git.me@ttaylorr.com>
This is another new round of my series to implement bitmap support for
incremental multi-pack indexes (MIDXs). It is still based on 683c54c999
(Git 2.49, 2025-03-14).
== Changes since last time
This round addresses thorough review from Elijah and Peff. The series
substantively is unchanged, but there are lots of little quality-of-life
and commit message readability improvements throughout. As usual, there
is a range-diff below for convenience.
== Original cover letter
This series is based on 'master', with an additional merge between
tb/incremental-midx-part-1[1] and my newer series to fix a handful of
bugs related to pseudo-merge bitmaps[2].
This is the second of three series to implement support for incremental
multi-pack indexes (MIDXs). This series brings support for bitmaps that
are tied to incremental MIDXs in addition to regular MIDX bitmaps.
The details are laid out in the commits themselves, but the high-level
approach is as follows:
- Each layer in the incremental MIDX chain has its own corresponding
*.bitmap file. Each bitmap contains commits / pseudo-merges which
are selected only from the commits in that layer. Likewise, only
that layer's objects are written in the type-level bitmaps.
- The reachability traversal is only conducted on the top-most bitmap
corresponding to the most recent layer in the incremental MIDX
chain. Earlier layers may be consulted to retrieve commit /
pseudo-merge reachability bitmaps, but only the top-most bitmap's
"result" and "haves" fields are used.
- In essence, the top-most bitmap is the only one that "matters", and
earlier bitmaps are merely used to look up commit and pseudo-merge
bitmaps from that layer.
- Whenever we need to look at the type-level bitmaps corresponding to
the whole incremental MIDX chain, a new "ewah_or_iterator" is used.
This works in concept like a typical ewah_iterator, except works
over many EWAH bitmaps in parallel, OR-ing their results together
before returning them to the user.
In effect, this allows us to treat the union of all type-level
bitmaps (each of which only stores information about the objects its
corresponding layer within the incremental MIDX chain) as a single
type-level bitmap corresponding to all of the objects across every
layer of the incremental MIDX chain.
The sum total of this series is that we are able to append new commits /
pseudo-merges to a repository's reachability bitmaps without having to
rewrite existing bitmaps, making the operation much cheaper to perform
in large repositories.
The series is laid out roughly as follows:
- The first patch describes the technical details of incremental MIDX
bitmaps.
- The second patch adjusts the pack-revindex internals to prepare for
incremental MIDX bitmaps.
- The next seven patches adjust various components of the pack-bitmap
internals to do the same.
- The next three patches introduce and adjust callers to use the
ewah_or_iterator (as above).
- The final patch implements writing incremental MIDX bitmaps, and
introduces tests.
After this series, the remaining goals for this project include being
able to compact contiguous runs of incremental MIDX layers into a single
layer to support growing the chain of MIDX layers without the chain
itself becoming too long.
Thanks in advance for your review!
[1]: https://lore.kernel.org/git/cover.1722958595.git.me@ttaylorr.com/
[2]: https://lore.kernel.org/git/cover.1723743050.git.me@ttaylorr.com/
Taylor Blau (14):
Documentation: remove a "future work" item from the MIDX docs
Documentation: describe incremental MIDX bitmaps
pack-revindex: prepare for incremental MIDX bitmaps
pack-bitmap.c: open and store incremental bitmap layers
pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
pack-bitmap.c: compute disk-usage with incremental MIDXs
pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
ewah: implement `struct ewah_or_iterator`
pack-bitmap.c: keep track of each layer's type bitmaps
pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
midx: implement writing incremental MIDX bitmaps
Documentation/technical/multi-pack-index.adoc | 82 ++++-
builtin/pack-objects.c | 3 +-
ewah/ewah_bitmap.c | 33 ++
ewah/ewok.h | 12 +
midx-write.c | 57 ++-
pack-bitmap-write.c | 65 +++-
pack-bitmap.c | 344 ++++++++++++++----
pack-bitmap.h | 4 +-
pack-revindex.c | 34 +-
t/t5334-incremental-multi-pack-index.sh | 87 +++++
10 files changed, 589 insertions(+), 132 deletions(-)
Range-diff against v4:
-: ---------- > 1: 6af65fdaac Documentation: remove a "future work" item from the MIDX docs
1: f565f2fff1 ! 2: 0897359506 Documentation: describe incremental MIDX bitmaps
@@ Documentation/technical/multi-pack-index.adoc: objects_nr($H2) + objects_nr($H1)
+`o1` and `o2` are compared as follows:
+
+1. If `o1` appears in an earlier layer of the MIDX chain than `o2`, then
-+ `o1` is considered less than `o2`.
++ `o1` sorts ahead of `o2`.
+
+2. Otherwise, if `o1` and `o2` appear in the same MIDX layer, and that
+ MIDX layer has no base, then if one of `pack(o1)` and `pack(o2)` is
-+ preferred and the other is not, then the preferred one sorts first. If
-+ there is a base layer (i.e. the MIDX layer is not the first layer in
-+ the chain), then if `pack(o1)` appears earlier in that MIDX layer's
-+ pack order, than `o1` is less than `o2`. Likewise if `pack(o2)`
-+ appears earlier, than the opposite is true.
++ preferred and the other is not, then the preferred one sorts ahead of
++ the non-preferred one. If there is a base layer (i.e. the MIDX layer
++ is not the first layer in the chain), then if `pack(o1)` appears
++ earlier in that MIDX layer's pack order, then `o1` sorts ahead of
++ `o2`. Likewise if `pack(o2)` appears earlier, then the opposite is
++ true.
+
+3. Otherwise, `o1` and `o2` appear in the same pack, and thus in the
+ same MIDX layer. Sort `o1` and `o2` by their offset within their
@@ Documentation/technical/multi-pack-index.adoc: objects_nr($H2) + objects_nr($H1)
+The structure of a `*.bitmap` file belonging to an incremental MIDX
+chain is identical to that of a non-incremental MIDX bitmap, or a
+classic single-pack bitmap. Since objects are added to the end of the
-+incremental MIDX's pseudo-pack order (see: above), it is possible to
++incremental MIDX's pseudo-pack order (see above), it is possible to
+extend a bitmap when appending to the end of a MIDX chain.
+
+(Note: it is possible likewise to compress a contiguous sequence of MIDX
-+incremental layers, and their `*.bitmap`(s) into a single layer and
++incremental layers, and their `*.bitmap` files into a single layer and
+`*.bitmap`, but this is not yet implemented.)
+
+The object positions used are global within the pseudo-pack order, so
2: f2a232e556 ! 3: 5eac0d1485 pack-revindex: prepare for incremental MIDX bitmaps
@@ Commit message
incremental or not.
- pack_pos_to_midx() and midx_to_pack_pos() now both take in a global
- object position in the MIDX pseudo-pack order, and finds the
+ object position in the MIDX pseudo-pack order, and find the
earliest containing MIDX (similar to midx.c::midx_for_object().
- midx_pack_order_cmp() adjusts its call to pack_pos_to_midx() by the
@@ pack-bitmap.c: static struct ewah_bitmap *read_bitmap_1(struct bitmap_index *ind
return read_bitmap(index->map, index->map_size, &index->map_pos);
}
-+static uint32_t bitmap_non_extended_bits(struct bitmap_index *index)
++static uint32_t bitmap_num_objects_total(struct bitmap_index *index)
+{
+ if (index->midx) {
+ struct multi_pack_index *m = index->midx;
@@ pack-bitmap.c: static inline int bitmap_position_extended(struct bitmap_index *b
if (pos < kh_end(positions)) {
int bitmap_pos = kh_value(positions, pos);
- return bitmap_pos + bitmap_num_objects(bitmap_git);
-+ return bitmap_pos + bitmap_non_extended_bits(bitmap_git);
++ return bitmap_pos + bitmap_num_objects_total(bitmap_git);
}
return -1;
@@ pack-bitmap.c: static int ext_index_add_object(struct bitmap_index *bitmap_git,
}
- return bitmap_pos + bitmap_num_objects(bitmap_git);
-+ return bitmap_pos + bitmap_non_extended_bits(bitmap_git);
++ return bitmap_pos + bitmap_num_objects_total(bitmap_git);
}
struct bitmap_show_data {
@@ pack-bitmap.c: static void show_extended_objects(struct bitmap_index *bitmap_git
- if (!bitmap_get(objects, st_add(bitmap_num_objects(bitmap_git), i)))
+ if (!bitmap_get(objects,
-+ st_add(bitmap_non_extended_bits(bitmap_git), i)))
++ st_add(bitmap_num_objects_total(bitmap_git),
++ i)))
continue;
obj = eindex->objects[i];
@@ pack-bitmap.c: static void filter_bitmap_exclude_type(struct bitmap_index *bitma
*/
for (i = 0; i < eindex->count; i++) {
- size_t pos = st_add(i, bitmap_num_objects(bitmap_git));
-+ size_t pos = st_add(i, bitmap_non_extended_bits(bitmap_git));
++ size_t pos = st_add(i, bitmap_num_objects_total(bitmap_git));
if (eindex->objects[i]->type == type &&
bitmap_get(to_filter, pos) &&
!bitmap_get(tips, pos))
@@ pack-bitmap.c: static unsigned long get_size_by_pos(struct bitmap_index *bitmap_
oi.sizep = &size;
- if (pos < bitmap_num_objects(bitmap_git)) {
-+ if (pos < bitmap_non_extended_bits(bitmap_git)) {
++ if (pos < bitmap_num_objects_total(bitmap_git)) {
struct packed_git *pack;
off_t ofs;
@@ pack-bitmap.c: static unsigned long get_size_by_pos(struct bitmap_index *bitmap_git,
+ die(_("unable to get size of %s"), oid_to_hex(&oid));
}
} else {
++ size_t eindex_pos = pos - bitmap_num_objects_total(bitmap_git);
struct eindex *eindex = &bitmap_git->ext_index;
- struct object *obj = eindex->objects[pos - bitmap_num_objects(bitmap_git)];
-+ struct object *obj = eindex->objects[pos - bitmap_non_extended_bits(bitmap_git)];
++ struct object *obj = eindex->objects[eindex_pos];
if (oid_object_info_extended(bitmap_repo(bitmap_git), &obj->oid,
&oi, 0) < 0)
die(_("unable to get size of %s"), oid_to_hex(&obj->oid));
@@ pack-bitmap.c: static void filter_packed_objects_from_bitmap(struct bitmap_index
size_t i, pos;
- objects_nr = bitmap_num_objects(bitmap_git);
-+ objects_nr = bitmap_non_extended_bits(bitmap_git);
++ objects_nr = bitmap_num_objects_total(bitmap_git);
pos = objects_nr / BITS_IN_EWORD;
if (pos > result->word_alloc)
@@ pack-bitmap.c: static uint32_t count_object_type(struct bitmap_index *bitmap_git
if (eindex->objects[i]->type == type &&
bitmap_get(objects,
- st_add(bitmap_num_objects(bitmap_git), i)))
-+ st_add(bitmap_non_extended_bits(bitmap_git), i)))
++ st_add(bitmap_num_objects_total(bitmap_git), i)))
count++;
}
@@ pack-bitmap.c: uint32_t *create_bitmap_mapping(struct bitmap_index *bitmap_git,
"extension");
- num_objects = bitmap_num_objects(bitmap_git);
-+ num_objects = bitmap_non_extended_bits(bitmap_git);
++ num_objects = bitmap_num_objects_total(bitmap_git);
CALLOC_ARRAY(reposition, num_objects);
for (i = 0; i < num_objects; ++i) {
@@ pack-bitmap.c: static off_t get_disk_usage_for_extended(struct bitmap_index *bit
if (!bitmap_get(result,
- st_add(bitmap_num_objects(bitmap_git), i)))
-+ st_add(bitmap_non_extended_bits(bitmap_git), i)))
++ st_add(bitmap_num_objects_total(bitmap_git),
++ i)))
continue;
if (oid_object_info_extended(bitmap_repo(bitmap_git), &obj->oid,
3: aca0318fb1 ! 4: 922ea2f607 pack-bitmap.c: open and store incremental bitmap layers
@@ Commit message
with the previous MIDX layer.
The changes in this commit are mostly boilerplate to open the correct
- bitmap(s), add them to the chain bitmap layers along the "base" pointer,
- ensures that the correct packs and their reverse indexes are loaded
- across MIDX layers, etc.
+ bitmap(s), add them to the chain of bitmap layers along the "base"
+ pointer, ensure that the correct packs and their reverse indexes are
+ loaded across MIDX layers, etc.
While we're at it, keep track of a base_nr field to indicate how many
bitmap layers (including the current bitmap) exist. This will be used in
4: 832fd0e8dc = 5: 8fedd96614 pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
5: c7c9f89956 = 6: dccc1b2d2e pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
6: 14d3d80c3d ! 7: e31bddd240 pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
@@ Commit message
Likewise, in reuse_partial_packfile_from_bitmap(), when reusing only a
single pack from a MIDX, use the oldest layer's preferred pack as it is
- likely to contain the most amount of reusable sections.
+ likely to contain the largest number of reusable sections.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
7: b45a9ccbc2 ! 8: d9dfcb5a1b pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
@@ pack-bitmap.c: static void test_show_commit(struct commit *commit, void *data)
+ tdata->tags = ewah_to_bitmap(bitmap_git->tags);
+
+ if (bitmap_git->base) {
-+ CALLOC_ARRAY(tdata->base_tdata, 1);
++ tdata->base_tdata = xmalloc(sizeof(struct bitmap_test_data));
+ bitmap_test_data_prepare(tdata->base_tdata, bitmap_git->base);
+ }
+}
8: c1eefeae99 = 9: b1bd60d25d pack-bitmap.c: compute disk-usage with incremental MIDXs
9: 11c4b7b949 = 10: 7477a8ac03 pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
10: cb08ad6a62 ! 11: 0fbef17acc ewah: implement `struct ewah_or_iterator`
@@ ewah/ewah_bitmap.c: void ewah_iterator_init(struct ewah_iterator *it, struct ewa
+ return ret;
+}
+
-+void ewah_or_iterator_free(struct ewah_or_iterator *it)
++void ewah_or_iterator_release(struct ewah_or_iterator *it)
+{
+ free(it->its);
+}
@@ ewah/ewok.h: void ewah_iterator_init(struct ewah_iterator *it, struct ewah_bitma
+
+int ewah_or_iterator_next(eword_t *next, struct ewah_or_iterator *it);
+
-+void ewah_or_iterator_free(struct ewah_or_iterator *it);
++void ewah_or_iterator_release(struct ewah_or_iterator *it);
+
void ewah_xor(
struct ewah_bitmap *ewah_i,
11: a29f4ee60d ! 12: 439e743fd5 pack-bitmap.c: keep track of each layer's type bitmaps
@@ pack-bitmap.c: struct bitmap_index {
+ * commits_all[n-2] is the commits field of this bitmap's
+ * 'base', and so on.
+ *
-+ * When either associated either with a non-incremental MIDX, or
-+ * a single packfile, these arrays each contain a single
-+ * element.
++ * When associated either with a non-incremental MIDX or a
++ * single packfile, these arrays each contain a single element.
+ */
+ struct ewah_bitmap **commits_all;
+ struct ewah_bitmap **trees_all;
12: a1cf65bedc ! 13: dcb45e349e pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
@@ pack-bitmap.c: static void show_objects_for_type(
}
}
+
-+ ewah_or_iterator_free(&it);
++ ewah_or_iterator_release(&it);
}
static int in_bitmapped_pack(struct bitmap_index *bitmap_git,
@@ pack-bitmap.c: static void filter_bitmap_exclude_type(struct bitmap_index *bitma
bitmap_unset(to_filter, pos);
}
-+ ewah_or_iterator_free(&it);
++ ewah_or_iterator_release(&it);
bitmap_free(tips);
}
@@ pack-bitmap.c: static void filter_bitmap_blob_limit(struct bitmap_index *bitmap_
bitmap_unset(to_filter, pos);
}
-+ ewah_or_iterator_free(&it);
++ ewah_or_iterator_release(&it);
bitmap_free(tips);
}
@@ pack-bitmap.c: static uint32_t count_object_type(struct bitmap_index *bitmap_git
count++;
}
-+ ewah_or_iterator_free(&it);
++ ewah_or_iterator_release(&it);
+
return count;
}
@@ pack-bitmap.c: static off_t get_disk_usage_for_type(struct bitmap_index *bitmap_
}
}
-+ ewah_or_iterator_free(&it);
++ ewah_or_iterator_release(&it);
+
return total;
}
13: d0d564685b ! 14: 13568cfa3b midx: implement writing incremental MIDX bitmaps
@@ builtin/pack-objects.c: static void write_pack_file(void)
bitmap_writer_build_type_index(&bitmap_writer,
written_list);
- ## ewah/ewah_bitmap.c ##
-@@ ewah/ewah_bitmap.c: int ewah_or_iterator_next(eword_t *next, struct ewah_or_iterator *it)
- return ret;
- }
-
--void ewah_or_iterator_free(struct ewah_or_iterator *it)
-+void ewah_or_iterator_release(struct ewah_or_iterator *it)
- {
- free(it->its);
- }
-
- ## ewah/ewok.h ##
-@@ ewah/ewok.h: void ewah_or_iterator_init(struct ewah_or_iterator *it,
-
- int ewah_or_iterator_next(eword_t *next, struct ewah_or_iterator *it);
-
--void ewah_or_iterator_free(struct ewah_or_iterator *it);
-+void ewah_or_iterator_release(struct ewah_or_iterator *it);
-
- void ewah_xor(
- struct ewah_bitmap *ewah_i,
-
## midx-write.c ##
@@ midx-write.c: static uint32_t *midx_pack_order(struct write_midx_context *ctx)
return pack_order;
@@ pack-bitmap-write.c: void bitmap_writer_finish(struct bitmap_writer *writer,
write_selected_commits_v1(writer, f, offsets);
- ## pack-bitmap.c ##
-@@ pack-bitmap.c: static void show_objects_for_type(
- }
- }
-
-- ewah_or_iterator_free(&it);
-+ ewah_or_iterator_release(&it);
- }
-
- static int in_bitmapped_pack(struct bitmap_index *bitmap_git,
-@@ pack-bitmap.c: static void filter_bitmap_exclude_type(struct bitmap_index *bitmap_git,
- bitmap_unset(to_filter, pos);
- }
-
-- ewah_or_iterator_free(&it);
-+ ewah_or_iterator_release(&it);
- bitmap_free(tips);
- }
-
-@@ pack-bitmap.c: static void filter_bitmap_blob_limit(struct bitmap_index *bitmap_git,
- bitmap_unset(to_filter, pos);
- }
-
-- ewah_or_iterator_free(&it);
-+ ewah_or_iterator_release(&it);
- bitmap_free(tips);
- }
-
-@@ pack-bitmap.c: static uint32_t count_object_type(struct bitmap_index *bitmap_git,
- count++;
- }
-
-- ewah_or_iterator_free(&it);
-+ ewah_or_iterator_release(&it);
-
- return count;
- }
-@@ pack-bitmap.c: static off_t get_disk_usage_for_type(struct bitmap_index *bitmap_git,
- }
- }
-
-- ewah_or_iterator_free(&it);
-+ ewah_or_iterator_release(&it);
-
- return total;
- }
-
## pack-bitmap.h ##
@@ pack-bitmap.h: struct bitmap_writer {
@@ t/t5334-incremental-multi-pack-index.sh: test_expect_success 'convert incrementa
+'
+
+test_expect_success 'midx verify with multiple layers' '
++ test_path_is_file "$midx_chain" &&
++ test_line_count = 2 "$midx_chain" &&
++
+ git multi-pack-index verify
+'
+
base-commit: 683c54c999c301c2cd6f715c411407c413b1d84e
--
2.49.0.14.g88b49c1b34
next prev parent reply other threads:[~2025-03-20 17:56 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 21:01 [PATCH 00/13] midx: incremental multi-pack indexes, part two Taylor Blau
2024-08-15 21:01 ` [PATCH 01/13] Documentation: describe incremental MIDX bitmaps Taylor Blau
2024-08-15 21:01 ` [PATCH 02/13] pack-revindex: prepare for " Taylor Blau
2024-08-15 21:01 ` [PATCH 03/13] pack-bitmap.c: open and store incremental bitmap layers Taylor Blau
2024-08-15 21:01 ` [PATCH 04/13] pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs Taylor Blau
2024-08-15 21:01 ` [PATCH 05/13] pack-bitmap.c: teach `show_objects_for_type()` " Taylor Blau
2024-08-15 21:01 ` [PATCH 06/13] pack-bitmap.c: support bitmap pack-reuse with " Taylor Blau
2024-08-15 21:01 ` [PATCH 07/13] pack-bitmap.c: teach `rev-list --test-bitmap` about " Taylor Blau
2024-08-15 21:01 ` [PATCH 08/13] pack-bitmap.c: compute disk-usage with " Taylor Blau
2024-08-15 21:01 ` [PATCH 09/13] pack-bitmap.c: apply pseudo-merge commits " Taylor Blau
2024-08-15 21:01 ` [PATCH 10/13] ewah: implement `struct ewah_or_iterator` Taylor Blau
2024-08-15 21:01 ` [PATCH 11/13] pack-bitmap.c: keep track of each layer's type bitmaps Taylor Blau
2024-08-15 21:01 ` [PATCH 12/13] pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators Taylor Blau
2024-08-15 21:01 ` [PATCH 13/13] midx: implement writing incremental MIDX bitmaps Taylor Blau
2024-08-15 22:28 ` [PATCH v2 00/13] midx: incremental multi-pack indexes, part two Taylor Blau
2024-08-15 22:28 ` [PATCH v2 01/13] Documentation: describe incremental MIDX bitmaps Taylor Blau
2024-08-15 22:28 ` [PATCH v2 02/13] pack-revindex: prepare for " Taylor Blau
2024-08-15 22:28 ` [PATCH v2 03/13] pack-bitmap.c: open and store incremental bitmap layers Taylor Blau
2024-08-15 22:29 ` [PATCH v2 04/13] pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs Taylor Blau
2024-08-15 22:29 ` [PATCH v2 05/13] pack-bitmap.c: teach `show_objects_for_type()` " Taylor Blau
2024-08-15 22:29 ` [PATCH v2 06/13] pack-bitmap.c: support bitmap pack-reuse with " Taylor Blau
2024-08-15 22:29 ` [PATCH v2 07/13] pack-bitmap.c: teach `rev-list --test-bitmap` about " Taylor Blau
2024-08-15 22:29 ` [PATCH v2 08/13] pack-bitmap.c: compute disk-usage with " Taylor Blau
2024-08-15 22:29 ` [PATCH v2 09/13] pack-bitmap.c: apply pseudo-merge commits " Taylor Blau
2024-08-15 22:29 ` [PATCH v2 10/13] ewah: implement `struct ewah_or_iterator` Taylor Blau
2024-08-15 22:29 ` [PATCH v2 11/13] pack-bitmap.c: keep track of each layer's type bitmaps Taylor Blau
2024-08-15 22:29 ` [PATCH v2 12/13] pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators Taylor Blau
2024-08-15 22:29 ` [PATCH v2 13/13] midx: implement writing incremental MIDX bitmaps Taylor Blau
2024-08-28 17:55 ` [PATCH] fixup! " Junio C Hamano
2024-08-28 18:33 ` Jeff King
2024-08-29 18:57 ` Taylor Blau
2024-08-29 19:27 ` Jeff King
2024-11-19 20:56 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 00/13] midx: incremental multi-pack indexes, part two Taylor Blau
2024-11-19 22:07 ` [PATCH v3 01/13] Documentation: describe incremental MIDX bitmaps Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-02-28 23:26 ` Taylor Blau
2025-03-03 10:54 ` Patrick Steinhardt
2024-11-19 22:07 ` [PATCH v3 02/13] pack-revindex: prepare for " Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-02-28 23:39 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 03/13] pack-bitmap.c: open and store incremental bitmap layers Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-02-28 23:49 ` Taylor Blau
2025-03-03 10:55 ` Patrick Steinhardt
2024-11-19 22:07 ` [PATCH v3 04/13] pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:12 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 05/13] pack-bitmap.c: teach `show_objects_for_type()` " Taylor Blau
2024-11-19 22:07 ` [PATCH v3 06/13] pack-bitmap.c: support bitmap pack-reuse with " Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:16 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 07/13] pack-bitmap.c: teach `rev-list --test-bitmap` about " Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:19 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 08/13] pack-bitmap.c: compute disk-usage with " Taylor Blau
2024-11-19 22:07 ` [PATCH v3 09/13] pack-bitmap.c: apply pseudo-merge commits " Taylor Blau
2024-11-19 22:07 ` [PATCH v3 10/13] ewah: implement `struct ewah_or_iterator` Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:22 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 11/13] pack-bitmap.c: keep track of each layer's type bitmaps Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:26 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 12/13] pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:28 ` Taylor Blau
2024-11-19 22:07 ` [PATCH v3 13/13] midx: implement writing incremental MIDX bitmaps Taylor Blau
2025-02-28 10:01 ` Patrick Steinhardt
2025-03-01 0:31 ` Taylor Blau
2024-11-20 8:49 ` [PATCH v3 00/13] midx: incremental multi-pack indexes, part two Junio C Hamano
2025-03-14 20:18 ` [PATCH v4 " Taylor Blau
2025-03-14 20:18 ` [PATCH v4 01/13] Documentation: describe incremental MIDX bitmaps Taylor Blau
2025-03-18 1:16 ` Jeff King
2025-03-18 23:11 ` Taylor Blau
2025-03-18 2:42 ` Elijah Newren
2025-03-18 23:19 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 02/13] pack-revindex: prepare for " Taylor Blau
2025-03-18 1:27 ` Jeff King
2025-03-19 0:02 ` Taylor Blau
2025-03-19 0:07 ` Taylor Blau
2025-03-26 18:08 ` Jeff King
2025-03-18 2:43 ` Elijah Newren
2025-03-19 0:03 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 03/13] pack-bitmap.c: open and store incremental bitmap layers Taylor Blau
2025-03-18 4:13 ` Elijah Newren
2025-03-19 0:08 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 04/13] pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs Taylor Blau
2025-03-18 1:38 ` Jeff King
2025-03-19 0:13 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 05/13] pack-bitmap.c: teach `show_objects_for_type()` " Taylor Blau
2025-03-14 20:18 ` [PATCH v4 06/13] pack-bitmap.c: support bitmap pack-reuse with " Taylor Blau
2025-03-18 4:13 ` Elijah Newren
2025-03-19 0:17 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 07/13] pack-bitmap.c: teach `rev-list --test-bitmap` about " Taylor Blau
2025-03-18 5:31 ` Elijah Newren
2025-03-19 0:30 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 08/13] pack-bitmap.c: compute disk-usage with " Taylor Blau
2025-03-18 1:41 ` Jeff King
2025-03-19 0:30 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 09/13] pack-bitmap.c: apply pseudo-merge commits " Taylor Blau
2025-03-14 20:18 ` [PATCH v4 10/13] ewah: implement `struct ewah_or_iterator` Taylor Blau
2025-03-18 1:44 ` Jeff King
2025-03-19 0:33 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 11/13] pack-bitmap.c: keep track of each layer's type bitmaps Taylor Blau
2025-03-18 2:01 ` Jeff King
2025-03-19 0:38 ` Taylor Blau
2025-03-18 6:43 ` Elijah Newren
2025-03-19 0:39 ` Taylor Blau
2025-03-14 20:18 ` [PATCH v4 12/13] pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators Taylor Blau
2025-03-18 2:05 ` Jeff King
2025-03-19 23:02 ` Taylor Blau
2025-03-14 20:19 ` [PATCH v4 13/13] midx: implement writing incremental MIDX bitmaps Taylor Blau
2025-03-18 2:16 ` Jeff King
2025-03-20 0:14 ` Taylor Blau
2025-03-18 17:13 ` Elijah Newren
2025-03-20 0:16 ` Taylor Blau
2025-03-18 2:21 ` [PATCH v4 00/13] midx: incremental multi-pack indexes, part two Jeff King
2025-03-20 0:18 ` Taylor Blau
2025-03-20 17:56 ` Taylor Blau [this message]
2025-03-20 17:56 ` [PATCH v5 01/14] Documentation: remove a "future work" item from the MIDX docs Taylor Blau
2025-03-20 17:56 ` [PATCH v5 02/14] Documentation: describe incremental MIDX bitmaps Taylor Blau
2025-03-20 17:56 ` [PATCH v5 03/14] pack-revindex: prepare for " Taylor Blau
2025-03-20 17:56 ` [PATCH v5 04/14] pack-bitmap.c: open and store incremental bitmap layers Taylor Blau
2025-03-20 17:56 ` [PATCH v5 05/14] pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs Taylor Blau
2025-03-20 17:56 ` [PATCH v5 06/14] pack-bitmap.c: teach `show_objects_for_type()` " Taylor Blau
2025-03-20 17:56 ` [PATCH v5 07/14] pack-bitmap.c: support bitmap pack-reuse with " Taylor Blau
2025-03-20 17:56 ` [PATCH v5 08/14] pack-bitmap.c: teach `rev-list --test-bitmap` about " Taylor Blau
2025-03-20 17:56 ` Taylor Blau
2025-03-20 17:58 ` Taylor Blau
2025-03-20 17:56 ` [PATCH v5 09/14] pack-bitmap.c: compute disk-usage with " Taylor Blau
2025-03-20 17:56 ` [PATCH v5 10/14] pack-bitmap.c: apply pseudo-merge commits " Taylor Blau
2025-03-20 17:56 ` [PATCH v5 11/14] ewah: implement `struct ewah_or_iterator` Taylor Blau
2025-03-20 17:57 ` [PATCH v5 12/14] pack-bitmap.c: keep track of each layer's type bitmaps Taylor Blau
2025-03-20 17:57 ` [PATCH v5 13/14] pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators Taylor Blau
2025-03-20 17:57 ` [PATCH v5 14/14] midx: implement writing incremental MIDX bitmaps Taylor Blau
2025-03-20 20:00 ` [PATCH v5 00/14] midx: incremental multi-pack indexes, part two Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1742493373.git.me@ttaylorr.com \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).