Git 2.33 (Q3 2021) is now clearer regarding git repack --max-pack-size=...
.
See commit 6fb9195 (08 Jun 2021) by Jeff King (peff
).
(Merged by Junio C Hamano -- gitster
-- in commit 18b49be, 08 Jul 2021)
doc
: warn people against --max-pack-size
Signed-off-by: Jeff King
This option is almost never a good idea, as the resulting repository is larger and slower (see the new explanations in the docs).
I outlined the potential problems.
We could go further and make the option harder to find (or at least, make the command-line option descriptions a much more terse "you probably don't want this; see pack.packsizeLimit
for details").
But this seems like a minimal change that may prevent people from thinking it's more useful than it is.
git config
now includes in its man page:
Note that this option is rarely useful, and may result in a larger total
on-disk size (because Git will not store deltas between packs), as well
as worse runtime performance (object lookup within multiple packs is
slower than a single pack, and optimizations like reachability bitmaps
cannot cope with multiple packs).
If you need to actively run Git using smaller packfiles (e.g., because your
filesystem does not support large files), this option may help.
But if
your goal is to transmit a packfile over a medium that supports limited
sizes (e.g., removable media that cannot store the whole repository),
you are likely better off creating a single large packfile and splitting
it using a generic multi-volume archive tool (e.g., Unix split
).
The minimum size allowed is limited to 1 MiB. The default is unlimited.
Common unit suffixes of 'k', 'm', or 'g' are supported.
git pack-objects
now includes in its man page:
Note that this option may result in
a larger and slower repository; see the discussion in
pack.packSizeLimit
.
git repack
now includes in its man page:
Note that this option may result in
a larger and slower repository; see the discussion in
pack.packSizeLimit
.