]> git.ipfire.org Git - thirdparty/git.git/commit
p5332: drop "+" from --stdin-packs input
authorJeff King <peff@peff.net>
Tue, 22 Apr 2025 11:16:32 +0000 (07:16 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 22 Apr 2025 18:08:24 +0000 (11:08 -0700)
commit1aa50636fd5c6f9742f0258c10aa0f6503f2cde3
tree438464800dedac45271229b8a41ecc0616979fcb
parent2f323bb16219c105e0c576ea4c2ece9863f5d926
p5332: drop "+" from --stdin-packs input

This perf script creates a midx by running "git multi-pack-index write"
with the "--stdin-packs" option. We feed that stdin by running "find" on
.git/objects/pack, using sed to strip off everything but the basename.

But that sed invocation also does something peculiar: it adds a "+" to
the start of each pack name. This causes the multi-pack-index command to
barf. The modified name does not match any pack it knows about, so it
ends up with an empty list of packs to put in the midx. And thus nothing
matches the --preferred-pack option we pass, which causes it die().

The fix is to remove the extra "+" (which also lets us simplify the sed
invocation a bit, as it is now just stripping the leading directories).

But that leaves the mystery of why it was ever there in the first place.
The answer is that an earlier iteration of the patch series had a
concept of "disjoint" packs in the midx. And one of its patches here:

  https://lore.kernel.org/git/c52d7e7b27a9add4f58b8334db4fe4498af1c90f.1701198172.git.me@ttaylorr.com/

taught read_packs_from_stdin() to treat a leading "+" as marking a
disjoint pack. But in the second version of the series, which was
ultimately merged, that disjoint concept went away, and the code to
parse "+" did likewise. The regular regression tests were adjusted to
match, but this case in t/perf was forgotten.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/perf/p5332-multi-pack-reuse.sh