Skip to content

Commit 6fb9195

Browse files
peffgitster
authored andcommitted
doc: warn people against --max-pack-size
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. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 48bf2fa commit 6fb9195

File tree

3 files changed

+23
-10
lines changed

3 files changed

+23
-10
lines changed

Documentation/config/pack.txt

Lines changed: 17 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -99,12 +99,23 @@ pack.packSizeLimit::
9999
packing to a file when repacking, i.e. the git:// protocol
100100
is unaffected. It can be overridden by the `--max-pack-size`
101101
option of linkgit:git-repack[1]. Reaching this limit results
102-
in the creation of multiple packfiles; which in turn prevents
103-
bitmaps from being created.
104-
The minimum size allowed is limited to 1 MiB.
105-
The default is unlimited.
106-
Common unit suffixes of 'k', 'm', or 'g' are
107-
supported.
102+
in the creation of multiple packfiles.
103+
+
104+
Note that this option is rarely useful, and may result in a larger total
105+
on-disk size (because Git will not store deltas between packs), as well
106+
as worse runtime performance (object lookup within multiple packs is
107+
slower than a single pack, and optimizations like reachability bitmaps
108+
cannot cope with multiple packs).
109+
+
110+
If you need to actively run Git using smaller packfiles (e.g., because your
111+
filesystem does not support large files), this option may help. But if
112+
your goal is to transmit a packfile over a medium that supports limited
113+
sizes (e.g., removable media that cannot store the whole repository),
114+
you are likely better off creating a single large packfile and splitting
115+
it using a generic multi-volume archive tool (e.g., Unix `split`).
116+
+
117+
The minimum size allowed is limited to 1 MiB. The default is unlimited.
118+
Common unit suffixes of 'k', 'm', or 'g' are supported.
108119

109120
pack.useBitmaps::
110121
When true, git will use pack bitmaps (if available) when packing

Documentation/git-pack-objects.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -118,10 +118,10 @@ depth is 4095.
118118
into multiple independent packfiles, each not larger than the
119119
given size. The size can be suffixed with
120120
"k", "m", or "g". The minimum size allowed is limited to 1 MiB.
121-
This option
122-
prevents the creation of a bitmap index.
123121
The default is unlimited, unless the config variable
124-
`pack.packSizeLimit` is set.
122+
`pack.packSizeLimit` is set. Note that this option may result in
123+
a larger and slower repository; see the discussion in
124+
`pack.packSizeLimit`.
125125

126126
--honor-pack-keep::
127127
This flag causes an object already in a local pack that

Documentation/git-repack.txt

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -121,7 +121,9 @@ depth is 4095.
121121
If specified, multiple packfiles may be created, which also
122122
prevents the creation of a bitmap index.
123123
The default is unlimited, unless the config variable
124-
`pack.packSizeLimit` is set.
124+
`pack.packSizeLimit` is set. Note that this option may result in
125+
a larger and slower repository; see the discussion in
126+
`pack.packSizeLimit`.
125127

126128
-b::
127129
--write-bitmap-index::

0 commit comments

Comments
 (0)