Browse Source
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
Nguyễn Thái Ngọc Duy
6 years ago
committed by
Junio C Hamano
2 changed files with 121 additions and 120 deletions
@ -0,0 +1,120 @@
@@ -0,0 +1,120 @@
|
||||
pack.window:: |
||||
The size of the window used by linkgit:git-pack-objects[1] when no |
||||
window size is given on the command line. Defaults to 10. |
||||
|
||||
pack.depth:: |
||||
The maximum delta depth used by linkgit:git-pack-objects[1] when no |
||||
maximum depth is given on the command line. Defaults to 50. |
||||
Maximum value is 4095. |
||||
|
||||
pack.windowMemory:: |
||||
The maximum size of memory that is consumed by each thread |
||||
in linkgit:git-pack-objects[1] for pack window memory when |
||||
no limit is given on the command line. The value can be |
||||
suffixed with "k", "m", or "g". When left unconfigured (or |
||||
set explicitly to 0), there will be no limit. |
||||
|
||||
pack.compression:: |
||||
An integer -1..9, indicating the compression level for objects |
||||
in a pack file. -1 is the zlib default. 0 means no |
||||
compression, and 1..9 are various speed/size tradeoffs, 9 being |
||||
slowest. If not set, defaults to core.compression. If that is |
||||
not set, defaults to -1, the zlib default, which is "a default |
||||
compromise between speed and compression (currently equivalent |
||||
to level 6)." |
||||
+ |
||||
Note that changing the compression level will not automatically recompress |
||||
all existing objects. You can force recompression by passing the -F option |
||||
to linkgit:git-repack[1]. |
||||
|
||||
pack.island:: |
||||
An extended regular expression configuring a set of delta |
||||
islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] |
||||
for details. |
||||
|
||||
pack.islandCore:: |
||||
Specify an island name which gets to have its objects be |
||||
packed first. This creates a kind of pseudo-pack at the front |
||||
of one pack, so that the objects from the specified island are |
||||
hopefully faster to copy into any pack that should be served |
||||
to a user requesting these objects. In practice this means |
||||
that the island specified should likely correspond to what is |
||||
the most commonly cloned in the repo. See also "DELTA ISLANDS" |
||||
in linkgit:git-pack-objects[1]. |
||||
|
||||
pack.deltaCacheSize:: |
||||
The maximum memory in bytes used for caching deltas in |
||||
linkgit:git-pack-objects[1] before writing them out to a pack. |
||||
This cache is used to speed up the writing object phase by not |
||||
having to recompute the final delta result once the best match |
||||
for all objects is found. Repacking large repositories on machines |
||||
which are tight with memory might be badly impacted by this though, |
||||
especially if this cache pushes the system into swapping. |
||||
A value of 0 means no limit. The smallest size of 1 byte may be |
||||
used to virtually disable this cache. Defaults to 256 MiB. |
||||
|
||||
pack.deltaCacheLimit:: |
||||
The maximum size of a delta, that is cached in |
||||
linkgit:git-pack-objects[1]. This cache is used to speed up the |
||||
writing object phase by not having to recompute the final delta |
||||
result once the best match for all objects is found. |
||||
Defaults to 1000. Maximum value is 65535. |
||||
|
||||
pack.threads:: |
||||
Specifies the number of threads to spawn when searching for best |
||||
delta matches. This requires that linkgit:git-pack-objects[1] |
||||
be compiled with pthreads otherwise this option is ignored with a |
||||
warning. This is meant to reduce packing time on multiprocessor |
||||
machines. The required amount of memory for the delta search window |
||||
is however multiplied by the number of threads. |
||||
Specifying 0 will cause Git to auto-detect the number of CPU's |
||||
and set the number of threads accordingly. |
||||
|
||||
pack.indexVersion:: |
||||
Specify the default pack index version. Valid values are 1 for |
||||
legacy pack index used by Git versions prior to 1.5.2, and 2 for |
||||
the new pack index with capabilities for packs larger than 4 GB |
||||
as well as proper protection against the repacking of corrupted |
||||
packs. Version 2 is the default. Note that version 2 is enforced |
||||
and this config option ignored whenever the corresponding pack is |
||||
larger than 2 GB. |
||||
+ |
||||
If you have an old Git that does not understand the version 2 `*.idx` file, |
||||
cloning or fetching over a non native protocol (e.g. "http") |
||||
that will copy both `*.pack` file and corresponding `*.idx` file from the |
||||
other side may give you a repository that cannot be accessed with your |
||||
older version of Git. If the `*.pack` file is smaller than 2 GB, however, |
||||
you can use linkgit:git-index-pack[1] on the *.pack file to regenerate |
||||
the `*.idx` file. |
||||
|
||||
pack.packSizeLimit:: |
||||
The maximum size of a pack. This setting only affects |
||||
packing to a file when repacking, i.e. the git:// protocol |
||||
is unaffected. It can be overridden by the `--max-pack-size` |
||||
option of linkgit:git-repack[1]. Reaching this limit results |
||||
in the creation of multiple packfiles; which in turn prevents |
||||
bitmaps from being created. |
||||
The minimum size allowed is limited to 1 MiB. |
||||
The default is unlimited. |
||||
Common unit suffixes of 'k', 'm', or 'g' are |
||||
supported. |
||||
|
||||
pack.useBitmaps:: |
||||
When true, git will use pack bitmaps (if available) when packing |
||||
to stdout (e.g., during the server side of a fetch). Defaults to |
||||
true. You should not generally need to turn this off unless |
||||
you are debugging pack bitmaps. |
||||
|
||||
pack.writeBitmaps (deprecated):: |
||||
This is a deprecated synonym for `repack.writeBitmaps`. |
||||
|
||||
pack.writeBitmapHashCache:: |
||||
When true, git will include a "hash cache" section in the bitmap |
||||
index (if one is written). This cache can be used to feed git's |
||||
delta heuristics, potentially leading to better deltas between |
||||
bitmapped and non-bitmapped objects (e.g., when serving a fetch |
||||
between an older, bitmapped pack and objects that have been |
||||
pushed since the last gc). The downside is that it consumes 4 |
||||
bytes per object of disk space, and that JGit's bitmap |
||||
implementation does not understand it, causing it to complain if |
||||
Git and JGit are used on the same repository. Defaults to false. |
||||
Loading…
Reference in new issue