| | |
|---|
| | | # RESTART REQUIRED |
|---|
| | | git.packedGitOpenFiles = 128 |
|---|
| | | |
|---|
| | | # Largest object size, in bytes, that JGit will allocate as a contiguous byte |
|---|
| | | # array. Any file revision larger than this threshold will have to be streamed, |
|---|
| | | # typically requiring the use of temporary files under $GIT_DIR/objects to implement |
|---|
| | | # psuedo-random access during delta decompression. |
|---|
| | | # |
|---|
| | | # Servers with very high traffic should set this to be larger than the size of |
|---|
| | | # their common big files. For example a server managing the Android platform |
|---|
| | | # typically has to deal with ~10-12 MiB XML files, so 15 m would be a reasonable |
|---|
| | | # setting in that environment. Setting this too high may cause the JVM to run out |
|---|
| | | # of heap space when handling very big binary files, such as device firmware or |
|---|
| | | # CD-ROM ISO images. Make sure to adjust your JVM heap accordingly. |
|---|
| | | # |
|---|
| | | # Default is 50 MiB on all platforms. |
|---|
| | | # |
|---|
| | | # Common unit suffixes of k, m, or g are supported. |
|---|
| | | # Documentation courtesy of the Gerrit project. |
|---|
| | | # |
|---|
| | | # |
|---|
| | | # NOTE: The importance of JGit's streamFileTreshold AND Git's bigFileThreshold |
|---|
| | | # ISSUE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=394078 |
|---|
| | | # |
|---|
| | | # "core.bigFileThreshold |
|---|
| | | # |
|---|
| | | # Files larger than this size are stored deflated, without |
|---|
| | | # attempting delta compression. Storing large files without |
|---|
| | | # delta compression avoids excessive memory usage, at the |
|---|
| | | # slight expense of increased disk usage. |
|---|
| | | # |
|---|
| | | # Default is 512 MiB on all platforms. |
|---|
| | | # This should be reasonable for most projects as source code and other |
|---|
| | | # text files can still be delta compressed, |
|---|
| | | # but larger binary media files won't be." |
|---|
| | | # -- Git documentation |
|---|
| | | # |
|---|
| | | # If streamFileTreshold < bigFileTreshold you _may_ spend alot of time waiting |
|---|
| | | # for push and/or fetch to complete. It may even look hung. |
|---|
| | | # |
|---|
| | | # Until the issue is resolved gracefully, a workaround is to configure |
|---|
| | | # bigFileThreshold < streamFileTreshold AND then repack the repository. |
|---|
| | | # |
|---|
| | | # e.g. from the repository folder with Gitblit NOT running: |
|---|
| | | # git config core.bigFileTreshold 40m |
|---|
| | | # git gc --aggressive |
|---|
| | | # |
|---|
| | | # SINCE 1.0.0 |
|---|
| | | # RESTART REQUIRED |
|---|
| | | git.streamFileThreshold = 50m |
|---|
| | | |
|---|
| | | # When true, JGit will use mmap() rather than malloc()+read() to load data from |
|---|
| | | # pack files. The use of mmap can be problematic on some JVMs as the garbage |
|---|
| | | # collector must deduce that a memory mapped segment is no longer in use before |
|---|
