From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, dstolee@microsoft.com, gitster@pobox.com,
jonathantanmy@google.com
Subject: Re: [PATCH v2 13/24] pack-bitmap: read multi-pack bitmaps
Date: Wed, 21 Jul 2021 19:01:16 -0400 [thread overview]
Message-ID: <YPinPFW50Mj8cVkP@nand.local> (raw)
In-Reply-To: <YPgF4X2PeFvBuJXm@coredump.intra.peff.net>
On Wed, Jul 21, 2021 at 07:32:49AM -0400, Jeff King wrote:
> On Mon, Jun 21, 2021 at 06:25:31PM -0400, Taylor Blau wrote:
> > + if (!is_pack_valid(packfile)) {
> > + close(fd);
> > + return -1;
> > + }
> > +
>
> What's this extra is_pack_valid() doing? I wouldn't expect many changes
> at all to this non-midx code path (aside from the "did we already load a
> midx bitmap" in the earlier part of the hunk, which makes sense).
That looks like a mistake to me. I did a little digging and tried to
remember if it could have ever been useful, but I think that it's just a
stray change that has no value. Removed.
> > -static int load_pack_bitmap(struct bitmap_index *bitmap_git)
> > +static int load_reverse_index(struct bitmap_index *bitmap_git)
> > +{
> > + if (bitmap_is_midx(bitmap_git)) {
> > + uint32_t i;
> > + int ret;
> > +
> > + ret = load_midx_revindex(bitmap_git->midx);
> > + if (ret)
> > + return ret;
> > +
> > + for (i = 0; i < bitmap_git->midx->num_packs; i++) {
> > + if (prepare_midx_pack(the_repository, bitmap_git->midx, i))
> > + die(_("load_reverse_index: could not open pack"));
> > + ret = load_pack_revindex(bitmap_git->midx->packs[i]);
> > + if (ret)
> > + return ret;
> > + }
> > + return 0;
> > + }
> > + return load_pack_revindex(bitmap_git->pack);
> > +}
>
> OK, this new function is used in load_bitmap(), which is used for both
> pack and midx bitmaps. So if we have a midx bitmap, we'll
> unconditionally load the revindex here. But:
>
> - why do we then load individual pack revindexes? I can believe it may
> be necessary to meet the assumptions of some other part of the code,
> but it would be nice to have a comment giving us some clue.
Good suggestion. We will need to reference the reverse index belonging
to individual packs in a few locations in pack-objects (for e.g.,
write_reuse_object() calls offset_to_pack_pos(), and
pack_pos_to_offset(), both with arbitrary packs, not just the preferred
one).
I left the comment vague; something along the lines of "lots of routines
in pack-objects will need these structures to be ready to use".
I think there's room for improvement there, since for e.g., `git
rev-list --count --objects --use-bitmap-index` doesn't need to load the
reverse indexes. But that's already the case with classic bitmaps, too,
which eagerly call load_pack_revindex().
> - in open_midx_bitmap_1(), we also unconditionally load the midx
> reverse index. I think that will always happen before us here (we
> cannot load_bitmap() a bitmap that has not been opened). So is this
> load_midx_revindex() call always a noop?
Great catch. I removed the call to load_midx_revindex(), and replaced it
with a comment explaining why we don't need to call it (because we
already did).
> > static int bitmap_position(struct bitmap_index *bitmap_git,
> > const struct object_id *oid)
> > {
> > - int pos = bitmap_position_packfile(bitmap_git, oid);
> > + int pos;
> > + if (bitmap_is_midx(bitmap_git))
> > + pos = bitmap_position_midx(bitmap_git, oid);
> > + else
> > + pos = bitmap_position_packfile(bitmap_git, oid);
> > return (pos >= 0) ? pos : bitmap_position_extended(bitmap_git, oid);
> > }
>
> Makes sense. Not new in your patch, but this "int" return is fudging the
> same 32-bit space we were talking about elsewhere (i.e., "pos" really
> could be 2^32, or even more due to extended objects).
:-). It bothers me to no end, too, because of all of the recent effort
to improve the reverse-index APIs to avoid exactly this issue. But I
tend to agree that the concern is more theoretical than anything,
because we're only using the MSB, so the remaining 2^31 possible objects
still seems pretty generous.
> In practice I think even 2^31 objects is pretty out-of-reach, but it may
> be worth changing the return type (and the callers), or even just
> catching the overflow with an assertion.
Possibly, but keep in mind that the former is basically the same
refactor as we did with the "tell me whether this object was found via
this extra pointer". But bitmap_position() has a lot more callers than
that, so the plumbing required would be a little more prevalent.
So I'd be content to just punt on it for now, if you'd be OK with it.
> > if (pos < bitmap_num_objects(bitmap_git)) {
> > - off_t ofs = pack_pos_to_offset(pack, pos);
> > + struct packed_git *pack;
> > + off_t ofs;
> > +
> > + if (bitmap_is_midx(bitmap_git)) {
> > + uint32_t midx_pos = pack_pos_to_midx(bitmap_git->midx, pos);
> > + uint32_t pack_id = nth_midxed_pack_int_id(bitmap_git->midx, midx_pos);
> > +
> > + pack = bitmap_git->midx->packs[pack_id];
> > + ofs = nth_midxed_offset(bitmap_git->midx, midx_pos);
> > + } else {
> > + pack = bitmap_git->pack;
> > + ofs = pack_pos_to_offset(pack, pos);
> > + }
> > +
>
> All of the hunks like this make perfect sense. The big problem would be
> if we _missed_ a place that needed conversion to handle midx. But the
> nice thing is that it would segfault quickly in such an instance. So
> there I'm mostly relying on test coverage, plus our experience running
> with this code at scale.
Yeah; I'm definitely happy to rely on our experience running this and
related patches at GitHub for several months to give us confidence that
we didn't miss anything here.
> > static void try_partial_reuse(struct bitmap_index *bitmap_git,
> > + struct packed_git *pack,
> > size_t pos,
> > struct bitmap *reuse,
> > struct pack_window **w_curs)
> > {
> > - off_t offset, header;
> > + off_t offset, delta_obj_offset;
>
> I'm OK with all of this in one big patch. But I suspect you _could_
> just put:
>
> if (bitmap_git->midx)
> return; /* partial reuse not implemented for midx yet */
>
> to start with, and then actually implement it later. I call out this
> code in particular just because it's got a lot of subtleties (the
> "reuse" bits are much more intimate with the assumptions of packs and
> bitmaps than most other code).
>
> I'm not sure if it's worth the trouble at this point or not.
Yeah, I'd definitely err on the side of not splitting this up now,
especially since you've already gone through the whole patch and
reviewed it. (Of course, if your response was "this patch is way too
big, please split it up so I can more easily review it", that would be a
different story).
But I appreciate the advice, since I have felt that a lot of these
format-level changes require a 3-patch arc where:
- The first patch describes the new format in Documentation/technical.
- The second patch implements support for reading files that are
written in the new format.
- And finally, the third patch implements support for writing such
files.
...and it's usually the second of those three patches that is the most
complicated one by far. So this is a good way to split that patch up
into many pieces.
Of course, that only works if you delay adding tests until after support
is added for all parts of the new format, but that's more-or-less what
did here.
> > +static uint32_t midx_preferred_pack(struct bitmap_index *bitmap_git)
> > +{
> > + struct multi_pack_index *m = bitmap_git->midx;
> > + if (!m)
> > + BUG("midx_preferred_pack: requires non-empty MIDX");
> > + return nth_midxed_pack_int_id(m, pack_pos_to_midx(bitmap_git->midx, 0));
> > +}
>
> This part is really subtle. We infer the preferred pack by looking at
> the pack of the 0th bit position. In general that works, since that's
> part of the definition of the preferred pack.
>
> Could this ever be fooled if we had a preferred pack with 0 objects in
> it? I don't know why we would have such a thing, but just trying to
> think of cases where our assumptions might not hold (and what bad things
> could happen).
An empty preferred pack would cause a problem, yes. The solution is
two-fold (and incorporated into the reroll that I plan on sending
shortly):
- When the user specifies --preferred-pack, the MIDX code must make
sure that the given pack is non-empty. That's a new patch, and
basically adds a new conditional (to check the pack itself) and a
test (to make sure that we catch the case we are trying to prevent).
- When the user doesn't specify --preferred-pack (and instead asks us
to infer one for them) we want to select not just the oldest pack,
but the oldest *non-empty* pack. That is folded into the "midx:
infer preferred pack when not given one" patch.
In that patch, I made a note, but I think that it's subtle enough to
merit sharing here again. In the loop over all packs, the conditional for swapping out the oldest pack for the current one was something like:
if (p->mtime < oldest->mtime)
oldest = p;
but now we want it to be:
if (!oldest->num_objects || p->mtime < oldest->mtime)
oldest = p;
to reject packs that have no objects. And we want to be extra careful in
the case where the only pack fed to the MIDX writer was empty. But we
don't have to do anything there, since there are no objects to write
anyway, so any "preferred_idx" would be fine.
> > + if (bitmap_is_midx(bitmap_git))
> > + pack = bitmap_git->midx->packs[midx_preferred_pack(bitmap_git)];
> > + else
> > + pack = bitmap_git->pack;
> > + objects_nr = pack->num_objects;
> > +
> > while (i < result->word_alloc && result->words[i] == (eword_t)~0)
> > i++;
> >
> > - /* Don't mark objects not in the packfile */
> > + /*
> > + * Don't mark objects not in the packfile or preferred pack. This bitmap
> > + * marks objects eligible for reuse, but the pack-reuse code only
> > + * understands how to reuse a single pack. Since the preferred pack is
> > + * guaranteed to have all bases for its deltas (in a multi-pack bitmap),
> > + * we use it instead of another pack. In single-pack bitmaps, the choice
> > + * is made for us.
> > + */
> > if (i > objects_nr / BITS_IN_EWORD)
> > i = objects_nr / BITS_IN_EWORD;
>
> OK, so this clamps our "quick" contiguous set of bits to the number of
> objects in the preferred pack. Makes sense. And then we hit the
> object-by-object loop below...
>
> > @@ -1213,7 +1437,15 @@ int reuse_partial_packfile_from_bitmap(struct bitmap_index *bitmap_git,
> > break;
> >
> > offset += ewah_bit_ctz64(word >> offset);
> > - try_partial_reuse(bitmap_git, pos + offset, reuse, &w_curs);
> > + if (bitmap_is_midx(bitmap_git)) {
> > + /*
> > + * Can't reuse from a non-preferred pack (see
> > + * above).
> > + */
> > + if (pos + offset >= objects_nr)
> > + continue;
> > + }
> > + try_partial_reuse(bitmap_git, pack, pos + offset, reuse, &w_curs);
>
> ...and this likewise makes sure we never go past that first pack. Good.
>
> I think this "continue" could actually be a "break", as the loop is
> iterating over "offset" (and "pos + offset" always gets larger). In
> fact, it could break out of the outer loop as well (which is
> incrementing "pos"). It's probably a pretty small efficiency in
> practice, though.
Yeah; you're right. And we'll save up to BITS_IN_EWORD cycles of this
loop. (I wonder if smart-enough compilers will realize the same
optimization that you did and turn that `continue` into a `break`
automatically, but that's neither here nor there).
> > @@ -1511,8 +1749,13 @@ uint32_t *create_bitmap_mapping(struct bitmap_index *bitmap_git,
> > struct object_id oid;
> > struct object_entry *oe;
> >
> > - nth_packed_object_id(&oid, bitmap_git->pack,
> > - pack_pos_to_index(bitmap_git->pack, i));
> > + if (bitmap_is_midx(bitmap_git))
> > + nth_midxed_object_oid(&oid,
> > + bitmap_git->midx,
> > + pack_pos_to_midx(bitmap_git->midx, i));
> > + else
> > + nth_packed_object_id(&oid, bitmap_git->pack,
> > + pack_pos_to_index(bitmap_git->pack, i));
> > oe = packlist_find(mapping, &oid);
>
> Could this be using nth_bitmap_object_oid()? I guess not, because we are
> feeding from pack_pos_to_*. I'm not sure if another helper function is
> worth it (pack_pos_to_bitmap_index() or something?).
You're right that we can't call nth_bitmap_object_oid here directly,
sadly. But I think your suggestion for pack_pos_to_bitmap_index() (or
similar) would only benefit this caller, since most places that dispatch
conditionally to either pack_pos_to_{midx,index} want to pass the result
to a different function depending on which branch they took.
Definitely possible that I missed another case that would help, but that
was what I came up with after just a quick glance.
> > @@ -1575,7 +1831,31 @@ static off_t get_disk_usage_for_type(struct bitmap_index *bitmap_git,
> > break;
> >
> > offset += ewah_bit_ctz64(word >> offset);
> > - pos = base + offset;
> > +
> > + if (bitmap_is_midx(bitmap_git)) {
> > + uint32_t pack_pos;
> > + uint32_t midx_pos = pack_pos_to_midx(bitmap_git->midx, base + offset);
> > + uint32_t pack_id = nth_midxed_pack_int_id(bitmap_git->midx, midx_pos);
> > + off_t offset = nth_midxed_offset(bitmap_git->midx, midx_pos);
> > +
> > + pack = bitmap_git->midx->packs[pack_id];
> > +
> > + if (offset_to_pack_pos(pack, offset, &pack_pos) < 0) {
> > + struct object_id oid;
> > + nth_midxed_object_oid(&oid, bitmap_git->midx, midx_pos);
> > +
> > + die(_("could not find %s in pack #%"PRIu32" at offset %"PRIuMAX),
> > + oid_to_hex(&oid),
> > + pack_id,
> > + (uintmax_t)offset);
> > + }
> > +
> > + pos = pack_pos;
> > + } else {
> > + pack = bitmap_git->pack;
> > + pos = base + offset;
> > + }
> > +
> > total += pack_pos_to_offset(pack, pos + 1) -
> > pack_pos_to_offset(pack, pos);
> > }
>
> In the midx case, we have to go from midx-bitmap-pos to midx-index-pos,
> to then get the pack/ofs combo, which then gives us a real "pos" in the
> pack. I don't think there's a faster way to do it (and this is still
> much faster than looking up objects in the pack only to check their
> revindex).
>
> But then with the result, we compare the offset of "pos" and "pos + 1".
> We need to know "pos" to find "pos + 1". But in the midx case, don't we
> already have the offset of "pos" (it is "offset" in the bitmap_is_midx()
> conditional, which is shadowing the completely unrelated "offset" in the
> outer loop).
>
> We could reuse it, saving ourselves an extra round-trip of pack_pos to
> index_pos to offset. It would just mean stuffing the "total +=" line
> into the two sides of the conditional.
Yep; agreed. And it allows us to clean up a few little other things, so
I squashed it in. Thanks for the suggestion!
> > +off_t bitmap_pack_offset(struct bitmap_index *bitmap_git, uint32_t pos)
> > +{
> > + if (bitmap_is_midx(bitmap_git))
> > + return nth_midxed_offset(bitmap_git->midx,
> > + pack_pos_to_midx(bitmap_git->midx, pos));
> > + return nth_packed_object_offset(bitmap_git->pack,
> > + pack_pos_to_index(bitmap_git->pack, pos));
> > +}
>
> Does anybody call this function? I don't see any users by the end of the
> series.
Nope, great catch. I looked at callers of nth_midxed_offset and
nth_packed_object_offset to see if they could use this function and
weren't, but the spots I looked at didn't appear to be able that they
would be helped by the existence of this helper, so I just removed it.
Phew! This was quite the email to respond to, but I suppose that's my
fault for writing such a monstrous patch. Thank you for taking the time
to read through it all so carefully. I think you got the short end of
the stick between writing this email and responding to it, so thank you
:-).
Thanks,
Taylor
next prev parent reply other threads:[~2021-07-21 23:01 UTC|newest]
Thread overview: 273+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 18:10 [PATCH 00/22] multi-pack reachability bitmaps Taylor Blau
2021-04-09 18:10 ` [PATCH 01/22] pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps Taylor Blau
2021-04-09 18:10 ` [PATCH 02/22] pack-bitmap-write.c: gracefully fail to write non-closed bitmaps Taylor Blau
2021-04-16 2:46 ` Jonathan Tan
2021-04-09 18:10 ` [PATCH 03/22] pack-bitmap-write.c: free existing bitmaps Taylor Blau
2021-04-09 18:10 ` [PATCH 04/22] Documentation: build 'technical/bitmap-format' by default Taylor Blau
2021-04-09 18:11 ` [PATCH 05/22] Documentation: describe MIDX-based bitmaps Taylor Blau
2021-04-09 18:11 ` [PATCH 06/22] midx: make a number of functions non-static Taylor Blau
2021-04-09 18:11 ` [PATCH 07/22] midx: clear auxiliary .rev after replacing the MIDX Taylor Blau
2021-04-09 18:11 ` [PATCH 08/22] midx: respect 'core.multiPackIndex' when writing Taylor Blau
2021-04-09 18:11 ` [PATCH 09/22] pack-bitmap.c: introduce 'bitmap_num_objects()' Taylor Blau
2021-04-09 18:11 ` [PATCH 10/22] pack-bitmap.c: introduce 'nth_bitmap_object_oid()' Taylor Blau
2021-04-09 18:11 ` [PATCH 11/22] pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' Taylor Blau
2021-04-09 18:11 ` [PATCH 12/22] pack-bitmap: read multi-pack bitmaps Taylor Blau
2021-04-16 2:39 ` Jonathan Tan
2021-04-16 3:13 ` Taylor Blau
2021-04-09 18:11 ` [PATCH 13/22] pack-bitmap: write " Taylor Blau
2021-05-04 5:02 ` Jonathan Tan
2021-05-06 20:18 ` Taylor Blau
2021-05-06 22:00 ` Jonathan Tan
2021-04-09 18:11 ` [PATCH 14/22] t5310: move some tests to lib-bitmap.sh Taylor Blau
2021-04-09 18:11 ` [PATCH 15/22] t/helper/test-read-midx.c: add --checksum mode Taylor Blau
2021-04-09 18:12 ` [PATCH 16/22] t5326: test multi-pack bitmap behavior Taylor Blau
2021-05-04 17:51 ` Jonathan Tan
2021-04-09 18:12 ` [PATCH 17/22] t5310: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP Taylor Blau
2021-04-09 18:12 ` [PATCH 18/22] t5319: don't write MIDX bitmaps in t5319 Taylor Blau
2021-04-09 18:12 ` [PATCH 19/22] t7700: update to work with MIDX bitmap test knob Taylor Blau
2021-04-09 18:12 ` [PATCH 20/22] midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' Taylor Blau
2021-04-09 18:12 ` [PATCH 21/22] p5310: extract full and partial bitmap tests Taylor Blau
2021-04-09 18:12 ` [PATCH 22/22] p5326: perf tests for MIDX bitmaps Taylor Blau
2021-05-04 18:00 ` Jonathan Tan
2021-05-05 0:55 ` Junio C Hamano
2021-06-21 22:24 ` [PATCH v2 00/24] multi-pack reachability bitmaps Taylor Blau
2021-06-21 22:24 ` [PATCH v2 01/24] pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps Taylor Blau
2021-06-24 23:02 ` Ævar Arnfjörð Bjarmason
2021-07-14 17:24 ` Taylor Blau
2021-07-21 9:45 ` Jeff King
2021-07-21 17:15 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 02/24] pack-bitmap-write.c: gracefully fail to write non-closed bitmaps Taylor Blau
2021-06-24 23:23 ` Ævar Arnfjörð Bjarmason
2021-07-14 17:32 ` Taylor Blau
2021-07-14 18:44 ` Ævar Arnfjörð Bjarmason
2021-07-21 9:53 ` Jeff King
2021-07-21 9:50 ` Jeff King
2021-07-21 17:20 ` Taylor Blau
2021-07-23 7:37 ` Jeff King
2021-07-26 18:48 ` Taylor Blau
2021-07-27 17:11 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 03/24] pack-bitmap-write.c: free existing bitmaps Taylor Blau
2021-07-21 9:54 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 04/24] Documentation: build 'technical/bitmap-format' by default Taylor Blau
2021-06-24 23:35 ` Ævar Arnfjörð Bjarmason
2021-07-14 17:41 ` Taylor Blau
2021-07-14 22:58 ` Ævar Arnfjörð Bjarmason
2021-07-21 10:04 ` Jeff King
2021-07-21 10:10 ` Jeff King
2021-07-21 9:58 ` Jeff King
2021-07-21 10:08 ` Jeff King
2021-07-21 17:23 ` Taylor Blau
2021-07-23 7:39 ` Jeff King
2021-07-26 18:49 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 05/24] Documentation: describe MIDX-based bitmaps Taylor Blau
2021-07-21 10:18 ` Jeff King
2021-07-21 17:53 ` Taylor Blau
2021-07-23 7:45 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 06/24] midx: make a number of functions non-static Taylor Blau
2021-06-24 23:42 ` Ævar Arnfjörð Bjarmason
2021-07-14 23:01 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 07/24] midx: clear auxiliary .rev after replacing the MIDX Taylor Blau
2021-07-21 10:19 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 08/24] midx: respect 'core.multiPackIndex' when writing Taylor Blau
2021-06-24 23:43 ` Ævar Arnfjörð Bjarmason
2021-07-21 10:23 ` Jeff King
2021-07-21 19:22 ` Taylor Blau
2021-07-23 8:29 ` Jeff King
2021-07-26 18:59 ` Taylor Blau
2021-07-26 22:14 ` Taylor Blau
2021-07-27 17:29 ` Jeff King
2021-07-27 17:36 ` Taylor Blau
2021-07-27 17:42 ` Jeff King
2021-07-27 17:47 ` Taylor Blau
2021-07-27 17:55 ` Jeff King
2021-07-27 20:05 ` Taylor Blau
2021-07-28 17:46 ` Jeff King
2021-07-29 19:44 ` Taylor Blau
2021-08-12 19:59 ` Jeff King
2021-07-27 17:17 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 09/24] midx: infer preferred pack when not given one Taylor Blau
2021-07-21 10:34 ` Jeff King
2021-07-21 20:16 ` Taylor Blau
2021-07-23 8:50 ` Jeff King
2021-07-26 19:44 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 10/24] pack-bitmap.c: introduce 'bitmap_num_objects()' Taylor Blau
2021-07-21 10:35 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 11/24] pack-bitmap.c: introduce 'nth_bitmap_object_oid()' Taylor Blau
2021-06-24 14:59 ` Taylor Blau
2021-07-21 10:37 ` Jeff King
2021-07-21 10:38 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 12/24] pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' Taylor Blau
2021-07-21 10:39 ` Jeff King
2021-07-21 20:18 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 13/24] pack-bitmap: read multi-pack bitmaps Taylor Blau
2021-07-21 11:32 ` Jeff King
2021-07-21 23:01 ` Taylor Blau [this message]
2021-07-23 9:40 ` Jeff King
2021-07-23 10:00 ` Jeff King
2021-07-26 20:36 ` Taylor Blau
2021-06-21 22:25 ` [PATCH v2 14/24] pack-bitmap: write " Taylor Blau
2021-06-24 23:45 ` Ævar Arnfjörð Bjarmason
2021-07-15 14:33 ` Taylor Blau
2021-07-21 12:09 ` Jeff King
2021-07-26 18:12 ` Taylor Blau
2021-07-26 18:23 ` Taylor Blau
2021-07-27 17:11 ` Jeff King
2021-07-27 20:33 ` Taylor Blau
2021-07-28 17:52 ` Jeff King
2021-07-29 19:33 ` Taylor Blau
2021-08-12 20:00 ` Jeff King
2021-06-21 22:25 ` [PATCH v2 15/24] t5310: move some tests to lib-bitmap.sh Taylor Blau
2021-06-21 22:25 ` [PATCH v2 16/24] t/helper/test-read-midx.c: add --checksum mode Taylor Blau
2021-06-21 22:25 ` [PATCH v2 17/24] t5326: test multi-pack bitmap behavior Taylor Blau
2021-06-21 22:25 ` [PATCH v2 18/24] t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP Taylor Blau
2021-06-21 22:25 ` [PATCH v2 19/24] t5310: " Taylor Blau
2021-06-21 22:25 ` [PATCH v2 20/24] t5319: don't write MIDX bitmaps in t5319 Taylor Blau
2021-06-21 22:25 ` [PATCH v2 21/24] t7700: update to work with MIDX bitmap test knob Taylor Blau
2021-06-21 22:25 ` [PATCH v2 22/24] midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' Taylor Blau
2021-06-25 0:03 ` Ævar Arnfjörð Bjarmason
2021-06-21 22:25 ` [PATCH v2 23/24] p5310: extract full and partial bitmap tests Taylor Blau
2021-06-21 22:26 ` [PATCH v2 24/24] p5326: perf tests for MIDX bitmaps Taylor Blau
2021-06-25 9:06 ` [PATCH v2 00/24] multi-pack reachability bitmaps Ævar Arnfjörð Bjarmason
2021-07-15 14:36 ` Taylor Blau
2021-07-21 12:12 ` Jeff King
2021-07-27 21:19 ` [PATCH v3 00/25] " Taylor Blau
2021-07-27 21:19 ` [PATCH v3 01/25] pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps Taylor Blau
2021-07-27 21:19 ` [PATCH v3 02/25] pack-bitmap-write.c: gracefully fail to write non-closed bitmaps Taylor Blau
2021-07-27 21:19 ` [PATCH v3 03/25] pack-bitmap-write.c: free existing bitmaps Taylor Blau
2021-07-27 21:19 ` [PATCH v3 04/25] Documentation: describe MIDX-based bitmaps Taylor Blau
2021-07-27 21:19 ` [PATCH v3 05/25] midx: clear auxiliary .rev after replacing the MIDX Taylor Blau
2021-07-27 21:19 ` [PATCH v3 06/25] midx: reject empty `--preferred-pack`'s Taylor Blau
2021-07-27 21:19 ` [PATCH v3 07/25] midx: infer preferred pack when not given one Taylor Blau
2021-07-27 21:19 ` [PATCH v3 08/25] midx: close linked MIDXs, avoid leaking memory Taylor Blau
2021-07-27 21:19 ` [PATCH v3 09/25] midx: avoid opening multiple MIDXs when writing Taylor Blau
2021-07-29 19:30 ` Taylor Blau
2021-08-12 20:15 ` Jeff King
2021-08-12 20:22 ` Jeff King
2021-08-12 21:20 ` Taylor Blau
2021-07-27 21:19 ` [PATCH v3 10/25] pack-bitmap.c: introduce 'bitmap_num_objects()' Taylor Blau
2021-07-27 21:19 ` [PATCH v3 11/25] pack-bitmap.c: introduce 'nth_bitmap_object_oid()' Taylor Blau
2021-07-27 21:19 ` [PATCH v3 12/25] pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' Taylor Blau
2021-07-27 21:19 ` [PATCH v3 13/25] pack-bitmap.c: avoid redundant calls to try_partial_reuse Taylor Blau
2021-07-27 21:19 ` [PATCH v3 14/25] pack-bitmap: read multi-pack bitmaps Taylor Blau
2021-07-27 21:20 ` [PATCH v3 15/25] pack-bitmap: write " Taylor Blau
2021-07-27 21:20 ` [PATCH v3 16/25] t5310: move some tests to lib-bitmap.sh Taylor Blau
2021-08-12 20:25 ` Jeff King
2021-07-27 21:20 ` [PATCH v3 17/25] t/helper/test-read-midx.c: add --checksum mode Taylor Blau
2021-08-12 20:31 ` Jeff King
2021-08-12 21:31 ` Taylor Blau
2021-07-27 21:20 ` [PATCH v3 18/25] t5326: test multi-pack bitmap behavior Taylor Blau
2021-08-12 21:02 ` Jeff King
2021-08-12 21:07 ` Jeff King
2021-08-12 22:38 ` Taylor Blau
2021-08-12 23:23 ` Jeff King
2021-07-27 21:20 ` [PATCH v3 19/25] t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP Taylor Blau
2021-07-27 21:20 ` [PATCH v3 20/25] t5310: " Taylor Blau
2021-07-27 21:20 ` [PATCH v3 21/25] t5319: don't write MIDX bitmaps in t5319 Taylor Blau
2021-07-27 21:20 ` [PATCH v3 22/25] t7700: update to work with MIDX bitmap test knob Taylor Blau
2021-07-27 21:20 ` [PATCH v3 23/25] midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' Taylor Blau
2021-08-12 21:09 ` Jeff King
2021-07-27 21:20 ` [PATCH v3 24/25] p5310: extract full and partial bitmap tests Taylor Blau
2021-07-27 21:20 ` [PATCH v3 25/25] p5326: perf tests for MIDX bitmaps Taylor Blau
2021-08-12 21:18 ` Jeff King
2021-08-12 21:21 ` [PATCH v3 00/25] multi-pack reachability bitmaps Jeff King
2021-08-12 22:41 ` Taylor Blau
2021-08-24 16:15 ` [PATCH v4 " Taylor Blau
2021-08-24 16:15 ` [PATCH v4 01/25] pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps Taylor Blau
2021-08-24 16:15 ` [PATCH v4 02/25] pack-bitmap-write.c: gracefully fail to write non-closed bitmaps Taylor Blau
2021-08-24 16:15 ` [PATCH v4 03/25] pack-bitmap-write.c: free existing bitmaps Taylor Blau
2021-08-24 16:15 ` [PATCH v4 04/25] Documentation: describe MIDX-based bitmaps Taylor Blau
2021-08-24 16:16 ` [PATCH v4 05/25] midx: clear auxiliary .rev after replacing the MIDX Taylor Blau
2021-08-24 20:27 ` Junio C Hamano
2021-08-24 20:34 ` Taylor Blau
2021-08-24 21:12 ` Junio C Hamano
2021-08-24 21:24 ` Taylor Blau
2021-08-24 22:01 ` Taylor Blau
2021-08-24 22:04 ` Junio C Hamano
2021-08-24 22:06 ` Junio C Hamano
2021-08-24 22:10 ` Taylor Blau
2021-08-27 6:01 ` Junio C Hamano
2021-08-27 18:03 ` Taylor Blau
2021-08-29 22:56 ` Junio C Hamano
2021-08-30 0:07 ` Taylor Blau
2021-08-30 0:34 ` Junio C Hamano
2021-08-30 0:43 ` Taylor Blau
2021-08-30 22:10 ` brian m. carlson
2021-08-30 22:28 ` Junio C Hamano
2021-08-30 22:33 ` Taylor Blau
2021-08-31 5:19 ` Jeff King
2021-08-31 16:29 ` Junio C Hamano
2021-08-31 16:39 ` Taylor Blau
2021-08-31 17:44 ` Junio C Hamano
2021-08-31 18:48 ` Taylor Blau
2021-08-31 1:21 ` Derrick Stolee
2021-08-31 5:37 ` Jeff King
2021-08-31 16:33 ` Junio C Hamano
2021-08-31 16:43 ` Taylor Blau
2021-08-31 17:17 ` Derrick Stolee
2021-09-01 10:03 ` Jeff King
2021-08-24 16:16 ` [PATCH v4 06/25] midx: reject empty `--preferred-pack`'s Taylor Blau
2021-08-24 16:16 ` [PATCH v4 07/25] midx: infer preferred pack when not given one Taylor Blau
2021-08-24 16:16 ` [PATCH v4 08/25] midx: close linked MIDXs, avoid leaking memory Taylor Blau
2021-08-24 16:16 ` [PATCH v4 09/25] midx: avoid opening multiple MIDXs when writing Taylor Blau
2021-08-24 16:16 ` [PATCH v4 10/25] pack-bitmap.c: introduce 'bitmap_num_objects()' Taylor Blau
2021-08-24 16:16 ` [PATCH v4 11/25] pack-bitmap.c: introduce 'nth_bitmap_object_oid()' Taylor Blau
2021-08-24 16:16 ` [PATCH v4 12/25] pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' Taylor Blau
2021-08-24 16:16 ` [PATCH v4 13/25] pack-bitmap.c: avoid redundant calls to try_partial_reuse Taylor Blau
2021-08-24 16:16 ` [PATCH v4 14/25] pack-bitmap: read multi-pack bitmaps Taylor Blau
2021-08-24 16:16 ` [PATCH v4 15/25] pack-bitmap: write " Taylor Blau
2021-08-24 16:16 ` [PATCH v4 16/25] t5310: move some tests to lib-bitmap.sh Taylor Blau
2021-08-24 16:16 ` [PATCH v4 17/25] t/helper/test-read-midx.c: add --checksum mode Taylor Blau
2021-08-24 16:16 ` [PATCH v4 18/25] t5326: test multi-pack bitmap behavior Taylor Blau
2021-08-24 16:16 ` [PATCH v4 19/25] t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP Taylor Blau
2021-08-24 16:16 ` [PATCH v4 20/25] t5310: " Taylor Blau
2021-08-24 16:16 ` [PATCH v4 21/25] t5319: don't write MIDX bitmaps in t5319 Taylor Blau
2021-08-24 16:16 ` [PATCH v4 22/25] t7700: update to work with MIDX bitmap test knob Taylor Blau
2021-08-24 16:16 ` [PATCH v4 23/25] midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' Taylor Blau
2021-08-24 16:16 ` [PATCH v4 24/25] p5310: extract full and partial bitmap tests Taylor Blau
2021-08-24 16:16 ` [PATCH v4 25/25] p5326: perf tests for MIDX bitmaps Taylor Blau
2021-08-25 0:28 ` [PATCH v4 00/25] multi-pack reachability bitmaps Jeff King
2021-08-25 2:10 ` Taylor Blau
2021-08-25 2:13 ` Taylor Blau
2021-08-25 7:36 ` Jeff King
2021-08-25 7:48 ` Johannes Berg
2021-08-26 18:49 ` Taylor Blau
2021-08-26 21:22 ` Taylor Blau
2021-08-27 21:30 ` Jeff King
2021-08-29 22:42 ` Junio C Hamano
2021-08-31 20:51 ` [PATCH v5 00/27] " Taylor Blau
2021-08-31 20:51 ` [PATCH v5 01/27] pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps Taylor Blau
2021-08-31 20:51 ` [PATCH v5 02/27] pack-bitmap-write.c: gracefully fail to write non-closed bitmaps Taylor Blau
2021-08-31 20:51 ` [PATCH v5 03/27] pack-bitmap-write.c: free existing bitmaps Taylor Blau
2021-08-31 20:51 ` [PATCH v5 04/27] Documentation: describe MIDX-based bitmaps Taylor Blau
2021-08-31 20:51 ` [PATCH v5 05/27] midx: disallow running outside of a repository Taylor Blau
2021-08-31 20:51 ` [PATCH v5 06/27] midx: fix `*.rev` cleanups with `--object-dir` Taylor Blau
2021-08-31 20:51 ` [PATCH v5 07/27] midx: clear auxiliary .rev after replacing the MIDX Taylor Blau
2021-08-31 20:52 ` [PATCH v5 08/27] midx: reject empty `--preferred-pack`'s Taylor Blau
2021-08-31 20:52 ` [PATCH v5 09/27] midx: infer preferred pack when not given one Taylor Blau
2021-08-31 20:52 ` [PATCH v5 10/27] midx: close linked MIDXs, avoid leaking memory Taylor Blau
2021-08-31 20:52 ` [PATCH v5 11/27] midx: avoid opening multiple MIDXs when writing Taylor Blau
2021-08-31 20:52 ` [PATCH v5 12/27] pack-bitmap.c: introduce 'bitmap_num_objects()' Taylor Blau
2021-08-31 20:52 ` [PATCH v5 13/27] pack-bitmap.c: introduce 'nth_bitmap_object_oid()' Taylor Blau
2021-08-31 20:52 ` [PATCH v5 14/27] pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' Taylor Blau
2021-08-31 20:52 ` [PATCH v5 15/27] pack-bitmap.c: avoid redundant calls to try_partial_reuse Taylor Blau
2021-08-31 20:52 ` [PATCH v5 16/27] pack-bitmap: read multi-pack bitmaps Taylor Blau
2021-08-31 20:52 ` [PATCH v5 17/27] pack-bitmap: write " Taylor Blau
2021-08-31 20:52 ` [PATCH v5 18/27] t5310: move some tests to lib-bitmap.sh Taylor Blau
2021-08-31 20:52 ` [PATCH v5 19/27] t/helper/test-read-midx.c: add --checksum mode Taylor Blau
2021-08-31 20:52 ` [PATCH v5 20/27] t5326: test multi-pack bitmap behavior Taylor Blau
2021-08-31 20:52 ` [PATCH v5 21/27] t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP Taylor Blau
2021-08-31 20:52 ` [PATCH v5 22/27] t5310: " Taylor Blau
2021-08-31 20:52 ` [PATCH v5 23/27] t5319: don't write MIDX bitmaps in t5319 Taylor Blau
2021-08-31 20:52 ` [PATCH v5 24/27] t7700: update to work with MIDX bitmap test knob Taylor Blau
2021-08-31 20:52 ` [PATCH v5 25/27] midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' Taylor Blau
2021-08-31 20:52 ` [PATCH v5 26/27] p5310: extract full and partial bitmap tests Taylor Blau
2021-08-31 20:52 ` [PATCH v5 27/27] p5326: perf tests for MIDX bitmaps Taylor Blau
2021-09-01 18:07 ` [PATCH v5 00/27] multi-pack reachability bitmaps Junio C Hamano
2021-09-01 19:08 ` Taylor Blau
2021-09-01 19:23 ` Junio C Hamano
2021-09-01 20:34 ` Taylor Blau
2021-09-01 20:49 ` Junio C Hamano
2021-09-01 20:54 ` Taylor Blau
2021-09-02 9:40 ` Jeff King
2021-09-02 9:38 ` Jeff King
2021-09-02 9:45 ` Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YPinPFW50Mj8cVkP@nand.local \
--to=me@ttaylorr.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).