If a pack.packSizeLimit is set, we may split the pack data
across multiple packfiles. This means we cannot generate
.bitmap files, as they require that all of the reachable
objects are in the same pack. We check that condition when
we are generating the list of objects to pack (and disable
bitmaps if we are not packing everything), but we forgot to
update it when we notice that we needed to split (which
doesn't happen until the actual write phase).
The resulting bitmaps are quite bogus (they mention entries
that do not exist in the pack!) and can cause a fetch or
push to send insufficient objects.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
You should generally avoid splitting packs anyway, as it introduces
other inefficiencies, so I'm not really concerned about making bitmaps
work here (besides which, it would require a big change to the on-disk
format). The important thing here is avoiding creating the broken
bitmaps.
builtin/pack-objects.c | 1 +
t/t5310-pack-bitmaps.sh | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index d391934..a4022a7 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -811,6 +811,7 @@ static void write_pack_file(void)
fixup_pack_header_footer(fd, sha1, pack_tmp_name,
nr_written, sha1, offset);
close(fd);
+ write_bitmap_index = 0;
}
if (!pack_to_stdout) {
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 0580258..6003490 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -170,4 +170,13 @@ test_expect_success JGIT 'jgit can read our bitmaps' '
)
'
+test_expect_success 'splitting packs does not generate bogus bitmaps' '
+ test-genrandom foo $((1024 * 1024)) >rand &&
+ git add rand &&
+ git commit -m "commit with big file" &&
+ git -c pack.packSizeLimit=500k repack -adb &&
+ git init --bare no-bitmaps.git &&
+ git -C no-bitmaps.git fetch .. HEAD
+'
+
test_done
--
2.1.2.596.g7379948
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html