| 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 | |
| 30 | pack.allowPackReuse:: |
| 31 | When true or "single", and when reachability bitmaps are |
| 32 | enabled, pack-objects will try to send parts of the bitmapped |
| 33 | packfile verbatim. When "multi", and when a multi-pack |
| 34 | reachability bitmap is available, pack-objects will try to send |
| 35 | parts of all packs in the MIDX. |
| 36 | + |
| 37 | If only a single pack bitmap is available, and `pack.allowPackReuse` |
| 38 | is set to "multi", reuse parts of just the bitmapped packfile. This |
| 39 | can reduce memory and CPU usage to serve fetches, but might result in |
| 40 | sending a slightly larger pack. Defaults to true. |
| 41 | |
| 42 | pack.island:: |
| 43 | An extended regular expression configuring a set of delta |
| 44 | islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] |
| 45 | for details. |
| 46 | |
| 47 | pack.islandCore:: |
| 48 | Specify an island name which gets to have its objects be |
| 49 | packed first. This creates a kind of pseudo-pack at the front |
| 50 | of one pack, so that the objects from the specified island are |
| 51 | hopefully faster to copy into any pack that should be served |
| 52 | to a user requesting these objects. In practice this means |
| 53 | that the island specified should likely correspond to what is |
| 54 | the most commonly cloned in the repo. See also "DELTA ISLANDS" |
| 55 | in linkgit:git-pack-objects[1]. |
| 56 | |
| 57 | pack.deltaCacheSize:: |
| 58 | The maximum memory in bytes used for caching deltas in |
| 59 | linkgit:git-pack-objects[1] before writing them out to a pack. |
| 60 | This cache is used to speed up the writing object phase by not |
| 61 | having to recompute the final delta result once the best match |
| 62 | for all objects is found. Repacking large repositories on machines |
| 63 | which are tight with memory might be badly impacted by this though, |
| 64 | especially if this cache pushes the system into swapping. |
| 65 | A value of 0 means no limit. The smallest size of 1 byte may be |
| 66 | used to virtually disable this cache. Defaults to 256 MiB. |
| 67 | |
| 68 | pack.deltaCacheLimit:: |
| 69 | The maximum size of a delta, that is cached in |
| 70 | linkgit:git-pack-objects[1]. This cache is used to speed up the |
| 71 | writing object phase by not having to recompute the final delta |
| 72 | result once the best match for all objects is found. |
| 73 | Defaults to 1000. Maximum value is 65535. |
| 74 | |
| 75 | pack.threads:: |
| 76 | Specifies the number of threads to spawn when searching for best |
| 77 | delta matches. This requires that linkgit:git-pack-objects[1] |
| 78 | be compiled with pthreads otherwise this option is ignored with a |
| 79 | warning. This is meant to reduce packing time on multiprocessor |
| 80 | machines. The required amount of memory for the delta search window |
| 81 | is however multiplied by the number of threads. |
| 82 | Specifying 0 will cause Git to auto-detect the number of CPUs |
| 83 | and set the number of threads accordingly. |
| 84 | |
| 85 | pack.indexVersion:: |
| 86 | Specify the default pack index version. Valid values are 1 for |
| 87 | legacy pack index used by Git versions prior to 1.5.2, and 2 for |
| 88 | the new pack index with capabilities for packs larger than 4 GB |
| 89 | as well as proper protection against the repacking of corrupted |
| 90 | packs. Version 2 is the default. Note that version 2 is enforced |
| 91 | and this config option is ignored whenever the corresponding pack is |
| 92 | larger than 2 GB. |
| 93 | + |
| 94 | If you have an old Git that does not understand the version 2 `*.idx` file, |
| 95 | cloning or fetching over a non-native protocol (e.g. "http") |
| 96 | that will copy both `*.pack` file and corresponding `*.idx` file from the |
| 97 | other side may give you a repository that cannot be accessed with your |
| 98 | older version of Git. If the `*.pack` file is smaller than 2 GB, however, |
| 99 | you can use linkgit:git-index-pack[1] on the *.pack file to regenerate |
| 100 | the `*.idx` file. |
| 101 | |
| 102 | pack.packSizeLimit:: |
| 103 | The maximum size of a pack. This setting only affects |
| 104 | packing to a file when repacking, i.e. the git:// protocol |
| 105 | is unaffected. It can be overridden by the `--max-pack-size` |
| 106 | option of linkgit:git-repack[1]. Reaching this limit results |
| 107 | in the creation of multiple packfiles. |
| 108 | + |
| 109 | Note that this option is rarely useful, and may result in a larger total |
| 110 | on-disk size (because Git will not store deltas between packs) and |
| 111 | worse runtime performance (object lookup within multiple packs is |
| 112 | slower than a single pack, and optimizations like reachability bitmaps |
| 113 | cannot cope with multiple packs). |
| 114 | + |
| 115 | If you need to actively run Git using smaller packfiles (e.g., because your |
| 116 | filesystem does not support large files), this option may help. But if |
| 117 | your goal is to transmit a packfile over a medium that supports limited |
| 118 | sizes (e.g., removable media that cannot store the whole repository), |
| 119 | you are likely better off creating a single large packfile and splitting |
| 120 | it using a generic multi-volume archive tool (e.g., Unix `split`). |
| 121 | + |
| 122 | The minimum size allowed is limited to 1 MiB. The default is unlimited. |
| 123 | Common unit suffixes of 'k', 'm', or 'g' are supported. |
| 124 | |
| 125 | pack.useBitmaps:: |
| 126 | When true, git will use pack bitmaps (if available) when packing |
| 127 | to stdout (e.g., during the server side of a fetch). Defaults to |
| 128 | true. You should not generally need to turn this off unless |
| 129 | you are debugging pack bitmaps. |
| 130 | |
| 131 | pack.useBitmapBoundaryTraversal:: |
| 132 | When true, Git will use an experimental algorithm for computing |
| 133 | reachability queries with bitmaps. Instead of building up |
| 134 | complete bitmaps for all of the negated tips and then OR-ing |
| 135 | them together, consider negated tips with existing bitmaps as |
| 136 | additive (i.e. OR-ing them into the result if they exist, |
| 137 | ignoring them otherwise), and build up a bitmap at the boundary |
| 138 | instead. |
| 139 | + |
| 140 | When using this algorithm, Git may include too many objects as a result |
| 141 | of not opening up trees belonging to certain UNINTERESTING commits. This |
| 142 | inexactness matches the non-bitmap traversal algorithm. |
| 143 | + |
| 144 | In many cases, this can provide a speed-up over the exact algorithm, |
| 145 | particularly when there is poor bitmap coverage of the negated side of |
| 146 | the query. |
| 147 | |
| 148 | pack.useSparse:: |
| 149 | When true, git will default to using the '--sparse' option in |
| 150 | 'git pack-objects' when the '--revs' option is present. This |
| 151 | algorithm only walks trees that appear in paths that introduce new |
| 152 | objects. This can have significant performance benefits when |
| 153 | computing a pack to send a small change. However, it is possible |
| 154 | that extra objects are added to the pack-file if the included |
| 155 | commits contain certain types of direct renames. Default is |
| 156 | `true`. |
| 157 | |
| 158 | pack.usePathWalk:: |
| 159 | Enable the `--path-walk` option by default for `git pack-objects` |
| 160 | processes. See linkgit:git-pack-objects[1] for full details. |
| 161 | |
| 162 | pack.preferBitmapTips:: |
| 163 | Specifies a ref hierarchy (e.g., "refs/heads/"); can be |
| 164 | given multiple times to specify more than one hierarchy. |
| 165 | When selecting which commits will receive bitmaps, prefer a |
| 166 | commit at the tip of a reference that is contained in any of |
| 167 | the configured hierarchies. |
| 168 | + |
| 169 | Note that setting this configuration to `refs/foo/` does not mean that |
| 170 | the commits at the tips of `refs/foo/bar` and `refs/foo/baz` will |
| 171 | necessarily be selected. This is because commits are selected for |
| 172 | bitmaps from within a series of windows of variable length. |
| 173 | + |
| 174 | If a commit at the tip of any reference which is a suffix of any value |
| 175 | of this configuration is seen in a window, it is immediately given |
| 176 | preference over any other commit in that window. |
| 177 | |
| 178 | pack.writeBitmaps (deprecated):: |
| 179 | This is a deprecated synonym for `repack.writeBitmaps`. |
| 180 | |
| 181 | pack.writeBitmapHashCache:: |
| 182 | When true, git will include a "hash cache" section in the bitmap |
| 183 | index (if one is written). This cache can be used to feed git's |
| 184 | delta heuristics, potentially leading to better deltas between |
| 185 | bitmapped and non-bitmapped objects (e.g., when serving a fetch |
| 186 | between an older, bitmapped pack and objects that have been |
| 187 | pushed since the last gc). The downside is that it consumes 4 |
| 188 | bytes per object of disk space. Defaults to true. |
| 189 | + |
| 190 | When writing a multi-pack reachability bitmap, no new namehashes are |
| 191 | computed; instead, any namehashes stored in an existing bitmap are |
| 192 | permuted into their appropriate location when writing a new bitmap. |
| 193 | |
| 194 | pack.writeBitmapLookupTable:: |
| 195 | When true, Git will include a "lookup table" section in the |
| 196 | bitmap index (if one is written). This table is used to defer |
| 197 | loading individual bitmaps as late as possible. This can be |
| 198 | beneficial in repositories that have relatively large bitmap |
| 199 | indexes. Defaults to false. |
| 200 | |
| 201 | pack.readReverseIndex:: |
| 202 | When true, git will read any .rev file(s) that may be available |
| 203 | (see: linkgit:gitformat-pack[5]). When false, the reverse index |
| 204 | will be generated from scratch and stored in memory. Defaults to |
| 205 | true. |
| 206 | |
| 207 | pack.writeReverseIndex:: |
| 208 | When true, git will write a corresponding .rev file (see: |
| 209 | linkgit:gitformat-pack[5]) |
| 210 | for each new packfile that it writes in all places except for |
| 211 | linkgit:git-fast-import[1] and in the bulk checkin mechanism. |
| 212 | Defaults to true. |