summaryrefslogtreecommitdiff
path: root/builtin/repack.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2014-06-10 20:19:13 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-06-10 21:01:53 (GMT)
commit15a906c5e99fc34534fd40d61590da142dee71d2 (patch)
treec525d9831f29155faf63decab4c5fff09ee2d6e8 /builtin/repack.c
parentd078d85bc3cd74bbe1f230feb26cbe28f29d6d25 (diff)
downloadgit-15a906c5e99fc34534fd40d61590da142dee71d2.zip
git-15a906c5e99fc34534fd40d61590da142dee71d2.tar.gz
git-15a906c5e99fc34534fd40d61590da142dee71d2.tar.bz2
pack-objects: stop respecting pack.writebitmaps
The handling of the pack.writebitmaps config option originally happened in pack-objects, which is quite low-level. It would make more sense for drivers of pack-objects to read the config, and then manipulate pack-objects with command-line options. Recently, repack learned to do so, making the low-level read of pack.writebitmaps redundant here. Other callers, like upload-pack, would not generally want to write bitmaps anyway. This could be considered a regression for somebody who is driving pack-objects themselves outside of repack and expects the config option to be used. However, such users seem rather unlikely given how new the bitmap code is (and the fact that they would basically be reimplementing repack in the first place). Note that we do not do anything with pack.writeBitmapHashCache here. That option is not about "do we write bimaps", but rather "when we are writing bitmaps, how do we do it?". You would want that to kick in anytime you decide to write them, similar to how pack.indexVersion is used. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/repack.c')
0 files changed, 0 insertions, 0 deletions