]>
Commit | Line | Data |
---|---|---|
a168c5a2 NTND |
1 | pack.window:: |
2 | The size of the window used by linkgit:git-pack-objects[1] when no | |
3 | window size is given on the command line. Defaults to 10. | |
4 | ||
5 | pack.depth:: | |
6 | The maximum delta depth used by linkgit:git-pack-objects[1] when no | |
7 | maximum depth is given on the command line. Defaults to 50. | |
8 | Maximum value is 4095. | |
9 | ||
10 | pack.windowMemory:: | |
11 | The maximum size of memory that is consumed by each thread | |
12 | in linkgit:git-pack-objects[1] for pack window memory when | |
13 | no limit is given on the command line. The value can be | |
14 | suffixed with "k", "m", or "g". When left unconfigured (or | |
15 | set explicitly to 0), there will be no limit. | |
16 | ||
17 | pack.compression:: | |
18 | An integer -1..9, indicating the compression level for objects | |
19 | in a pack file. -1 is the zlib default. 0 means no | |
20 | compression, and 1..9 are various speed/size tradeoffs, 9 being | |
21 | slowest. If not set, defaults to core.compression. If that is | |
22 | not set, defaults to -1, the zlib default, which is "a default | |
23 | compromise between speed and compression (currently equivalent | |
24 | to level 6)." | |
25 | + | |
26 | Note that changing the compression level will not automatically recompress | |
27 | all existing objects. You can force recompression by passing the -F option | |
28 | to linkgit:git-repack[1]. | |
29 | ||
e704fc79 JK |
30 | pack.allowPackReuse:: |
31 | When true, and when reachability bitmaps are enabled, | |
32 | pack-objects will try to send parts of the bitmapped packfile | |
33 | verbatim. This can reduce memory and CPU usage to serve fetches, | |
34 | but might result in sending a slightly larger pack. Defaults to | |
35 | true. | |
36 | ||
a168c5a2 NTND |
37 | pack.island:: |
38 | An extended regular expression configuring a set of delta | |
39 | islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] | |
40 | for details. | |
41 | ||
42 | pack.islandCore:: | |
43 | Specify an island name which gets to have its objects be | |
44 | packed first. This creates a kind of pseudo-pack at the front | |
45 | of one pack, so that the objects from the specified island are | |
46 | hopefully faster to copy into any pack that should be served | |
47 | to a user requesting these objects. In practice this means | |
48 | that the island specified should likely correspond to what is | |
49 | the most commonly cloned in the repo. See also "DELTA ISLANDS" | |
50 | in linkgit:git-pack-objects[1]. | |
51 | ||
52 | pack.deltaCacheSize:: | |
53 | The maximum memory in bytes used for caching deltas in | |
54 | linkgit:git-pack-objects[1] before writing them out to a pack. | |
55 | This cache is used to speed up the writing object phase by not | |
56 | having to recompute the final delta result once the best match | |
57 | for all objects is found. Repacking large repositories on machines | |
58 | which are tight with memory might be badly impacted by this though, | |
59 | especially if this cache pushes the system into swapping. | |
60 | A value of 0 means no limit. The smallest size of 1 byte may be | |
61 | used to virtually disable this cache. Defaults to 256 MiB. | |
62 | ||
63 | pack.deltaCacheLimit:: | |
64 | The maximum size of a delta, that is cached in | |
65 | linkgit:git-pack-objects[1]. This cache is used to speed up the | |
66 | writing object phase by not having to recompute the final delta | |
67 | result once the best match for all objects is found. | |
68 | Defaults to 1000. Maximum value is 65535. | |
69 | ||
70 | pack.threads:: | |
71 | Specifies the number of threads to spawn when searching for best | |
72 | delta matches. This requires that linkgit:git-pack-objects[1] | |
73 | be compiled with pthreads otherwise this option is ignored with a | |
74 | warning. This is meant to reduce packing time on multiprocessor | |
75 | machines. The required amount of memory for the delta search window | |
76 | is however multiplied by the number of threads. | |
77 | Specifying 0 will cause Git to auto-detect the number of CPU's | |
78 | and set the number of threads accordingly. | |
79 | ||
80 | pack.indexVersion:: | |
81 | Specify the default pack index version. Valid values are 1 for | |
82 | legacy pack index used by Git versions prior to 1.5.2, and 2 for | |
83 | the new pack index with capabilities for packs larger than 4 GB | |
84 | as well as proper protection against the repacking of corrupted | |
85 | packs. Version 2 is the default. Note that version 2 is enforced | |
86 | and this config option ignored whenever the corresponding pack is | |
87 | larger than 2 GB. | |
88 | + | |
89 | If you have an old Git that does not understand the version 2 `*.idx` file, | |
90 | cloning or fetching over a non native protocol (e.g. "http") | |
91 | that will copy both `*.pack` file and corresponding `*.idx` file from the | |
92 | other side may give you a repository that cannot be accessed with your | |
93 | older version of Git. If the `*.pack` file is smaller than 2 GB, however, | |
94 | you can use linkgit:git-index-pack[1] on the *.pack file to regenerate | |
95 | the `*.idx` file. | |
96 | ||
97 | pack.packSizeLimit:: | |
98 | The maximum size of a pack. This setting only affects | |
99 | packing to a file when repacking, i.e. the git:// protocol | |
100 | is unaffected. It can be overridden by the `--max-pack-size` | |
101 | option of linkgit:git-repack[1]. Reaching this limit results | |
6fb9195f JK |
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. | |
a168c5a2 NTND |
119 | |
120 | pack.useBitmaps:: | |
121 | When true, git will use pack bitmaps (if available) when packing | |
122 | to stdout (e.g., during the server side of a fetch). Defaults to | |
123 | true. You should not generally need to turn this off unless | |
124 | you are debugging pack bitmaps. | |
125 | ||
3d036eb0 DS |
126 | pack.useSparse:: |
127 | When true, git will default to using the '--sparse' option in | |
128 | 'git pack-objects' when the '--revs' option is present. This | |
129 | algorithm only walks trees that appear in paths that introduce new | |
130 | objects. This can have significant performance benefits when | |
131 | computing a pack to send a small change. However, it is possible | |
132 | that extra objects are added to the pack-file if the included | |
de3a8641 DS |
133 | commits contain certain types of direct renames. Default is |
134 | `true`. | |
3d036eb0 | 135 | |
3f267a11 TB |
136 | pack.preferBitmapTips:: |
137 | When selecting which commits will receive bitmaps, prefer a | |
138 | commit at the tip of any reference that is a suffix of any value | |
139 | of this configuration over any other commits in the "selection | |
140 | window". | |
141 | + | |
142 | Note that setting this configuration to `refs/foo` does not mean that | |
143 | the commits at the tips of `refs/foo/bar` and `refs/foo/baz` will | |
144 | necessarily be selected. This is because commits are selected for | |
145 | bitmaps from within a series of windows of variable length. | |
146 | + | |
147 | If a commit at the tip of any reference which is a suffix of any value | |
148 | of this configuration is seen in a window, it is immediately given | |
149 | preference over any other commit in that window. | |
150 | ||
a168c5a2 NTND |
151 | pack.writeBitmaps (deprecated):: |
152 | This is a deprecated synonym for `repack.writeBitmaps`. | |
153 | ||
154 | pack.writeBitmapHashCache:: | |
155 | When true, git will include a "hash cache" section in the bitmap | |
156 | index (if one is written). This cache can be used to feed git's | |
157 | delta heuristics, potentially leading to better deltas between | |
158 | bitmapped and non-bitmapped objects (e.g., when serving a fetch | |
159 | between an older, bitmapped pack and objects that have been | |
160 | pushed since the last gc). The downside is that it consumes 4 | |
d4316604 | 161 | bytes per object of disk space. Defaults to true. |
caca3c9f TB |
162 | + |
163 | When writing a multi-pack reachability bitmap, no new namehashes are | |
164 | computed; instead, any namehashes stored in an existing bitmap are | |
165 | permuted into their appropriate location when writing a new bitmap. | |
1615c567 | 166 | |
76f14b77 AC |
167 | pack.writeBitmapLookupTable:: |
168 | When true, Git will include a "lookup table" section in the | |
169 | bitmap index (if one is written). This table is used to defer | |
170 | loading individual bitmaps as late as possible. This can be | |
171 | beneficial in repositories that have relatively large bitmap | |
172 | indexes. Defaults to false. | |
173 | ||
1615c567 TB |
174 | pack.writeReverseIndex:: |
175 | When true, git will write a corresponding .rev file (see: | |
977c47b4 | 176 | linkgit:gitformat-pack[5]) |
1615c567 TB |
177 | for each new packfile that it writes in all places except for |
178 | linkgit:git-fast-import[1] and in the bulk checkin mechanism. | |
179 | Defaults to false. |