1pack.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 5pack.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 10pack.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 17pack.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+ 26Note that changing the compression level will not automatically recompress 27all existing objects. You can force recompression by passing the -F option 28to linkgit:git-repack[1]. 29 30pack.island:: 31 An extended regular expression configuring a set of delta 32 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] 33 for details. 34 35pack.islandCore:: 36 Specify an island name which gets to have its objects be 37 packed first. This creates a kind of pseudo-pack at the front 38 of one pack, so that the objects from the specified island are 39 hopefully faster to copy into any pack that should be served 40 to a user requesting these objects. In practice this means 41 that the island specified should likely correspond to what is 42 the most commonly cloned in the repo. See also "DELTA ISLANDS" 43 in linkgit:git-pack-objects[1]. 44 45pack.deltaCacheSize:: 46 The maximum memory in bytes used for caching deltas in 47 linkgit:git-pack-objects[1] before writing them out to a pack. 48 This cache is used to speed up the writing object phase by not 49 having to recompute the final delta result once the best match 50 for all objects is found. Repacking large repositories on machines 51 which are tight with memory might be badly impacted by this though, 52 especially if this cache pushes the system into swapping. 53 A value of 0 means no limit. The smallest size of 1 byte may be 54 used to virtually disable this cache. Defaults to 256 MiB. 55 56pack.deltaCacheLimit:: 57 The maximum size of a delta, that is cached in 58 linkgit:git-pack-objects[1]. This cache is used to speed up the 59 writing object phase by not having to recompute the final delta 60 result once the best match for all objects is found. 61 Defaults to 1000. Maximum value is 65535. 62 63pack.threads:: 64 Specifies the number of threads to spawn when searching for best 65 delta matches. This requires that linkgit:git-pack-objects[1] 66 be compiled with pthreads otherwise this option is ignored with a 67 warning. This is meant to reduce packing time on multiprocessor 68 machines. The required amount of memory for the delta search window 69 is however multiplied by the number of threads. 70 Specifying 0 will cause Git to auto-detect the number of CPU's 71 and set the number of threads accordingly. 72 73pack.indexVersion:: 74 Specify the default pack index version. Valid values are 1 for 75 legacy pack index used by Git versions prior to 1.5.2, and 2 for 76 the new pack index with capabilities for packs larger than 4 GB 77 as well as proper protection against the repacking of corrupted 78 packs. Version 2 is the default. Note that version 2 is enforced 79 and this config option ignored whenever the corresponding pack is 80 larger than 2 GB. 81+ 82If you have an old Git that does not understand the version 2 `*.idx` file, 83cloning or fetching over a non native protocol (e.g. "http") 84that will copy both `*.pack` file and corresponding `*.idx` file from the 85other side may give you a repository that cannot be accessed with your 86older version of Git. If the `*.pack` file is smaller than 2 GB, however, 87you can use linkgit:git-index-pack[1] on the *.pack file to regenerate 88the `*.idx` file. 89 90pack.packSizeLimit:: 91 The maximum size of a pack. This setting only affects 92 packing to a file when repacking, i.e. the git:// protocol 93 is unaffected. It can be overridden by the `--max-pack-size` 94 option of linkgit:git-repack[1]. Reaching this limit results 95 in the creation of multiple packfiles; which in turn prevents 96 bitmaps from being created. 97 The minimum size allowed is limited to 1 MiB. 98 The default is unlimited. 99 Common unit suffixes of 'k', 'm', or 'g' are 100 supported. 101 102pack.useBitmaps:: 103 When true, git will use pack bitmaps (if available) when packing 104 to stdout (e.g., during the server side of a fetch). Defaults to 105 true. You should not generally need to turn this off unless 106 you are debugging pack bitmaps. 107 108pack.useSparse:: 109 When true, git will default to using the '--sparse' option in 110 'git pack-objects' when the '--revs' option is present. This 111 algorithm only walks trees that appear in paths that introduce new 112 objects. This can have significant performance benefits when 113 computing a pack to send a small change. However, it is possible 114 that extra objects are added to the pack-file if the included 115 commits contain certain types of direct renames. 116 117pack.writeBitmaps (deprecated):: 118 This is a deprecated synonym for `repack.writeBitmaps`. 119 120pack.writeBitmapHashCache:: 121 When true, git will include a "hash cache" section in the bitmap 122 index (if one is written). This cache can be used to feed git's 123 delta heuristics, potentially leading to better deltas between 124 bitmapped and non-bitmapped objects (e.g., when serving a fetch 125 between an older, bitmapped pack and objects that have been 126 pushed since the last gc). The downside is that it consumes 4 127 bytes per object of disk space, and that JGit's bitmap 128 implementation does not understand it, causing it to complain if 129 Git and JGit are used on the same repository. Defaults to false.