summaryrefslogtreecommitdiff
path: root/t/perf/p0001-rev-list.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2019-07-31 01:40:56 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-07-31 13:26:25 -0700
commit7ff024e7b3d576fc265dbdd1a7bd3dcc6dde1eb6 (patch)
tree9376851741e14429fa5e1e3f01d75800ff22a49c /t/perf/p0001-rev-list.sh
parentrepack: silence warnings when auto-enabled bitmaps cannot be built (diff)
downloadtgif-7ff024e7b3d576fc265dbdd1a7bd3dcc6dde1eb6.tar.xz
repack: simplify handling of auto-bitmaps and .keep files
Commit 7328482253 (repack: disable bitmaps-by-default if .keep files exist, 2019-06-29) taught repack to prefer disabling bitmaps to duplicating objects (unless bitmaps were asked for explicitly). But there's an easier way to do this: if we keep passing the --honor-pack-keep flag to pack-objects when auto-enabling bitmaps, then pack-objects already makes the same decision (it will disable bitmaps rather than duplicate). Better still, pack-objects can actually decide to do so based not just on the presence of a .keep file, but on whether that .keep file actually impacts the new pack we're making (so if we're racing with a push or fetch, for example, their temporary .keep file will not block us from generating bitmaps if they haven't yet updated their refs). And because repack uses the --write-bitmap-index-quiet flag, we don't have to worry about pack-objects generating confusing warnings when it does see a .keep file. We can confirm this by tweaking the .keep test to check repack's stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/perf/p0001-rev-list.sh')
0 files changed, 0 insertions, 0 deletions