DFS: A storage layer for JGit
In practice the DHT storage layer has not been performing as well as
large scale server environments want to see from a Git server.
The performance of the DHT schema degrades rapidly as small changes
are pushed into the repository due to the chunk size being less than
1/3 of the pushed pack size. Small chunks cause poor prefetch
performance during reading, and require significantly longer prefetch
lists inside of the chunk meta field to work around the small size.
The DHT code is very complex (>17,000 lines of code) and is very
sensitive to the underlying database round-trip time, as well as the
way objects were written into the pack stream that was chunked and
stored on the database. A poor pack layout (from any version of C Git
prior to Junio reworking it) can cause the DHT code to be unable to
enumerate the objects of the linux-2.6 repository in a completable
time scale.
Performing a clone from a DHT stored repository of 2 million objects
takes 2 million row lookups in the DHT to locate the OBJECT_INDEX row
for each object being cloned. This is very difficult for some DHTs to
scale, even at 5000 rows/second the lookup stage alone takes 6 minutes
(on local filesystem, this is almost too fast to bother measuring).
Some servers like Apache Cassandra just fall over and cannot complete
the 2 million lookups in rapid fire.
On a ~400 MiB repository, the DHT schema has an extra 25 MiB of
redundant data that gets downloaded to the JGit process, and that is
before you consider the cost of the OBJECT_INDEX table also being
fully loaded, which is at least 223 MiB of data for the linux kernel
repository. In the DHT schema answering a `git clone` of the ~400 MiB
linux kernel needs to load 248 MiB of "index" data from the DHT, in
addition to the ~400 MiB of pack data that gets sent to the client.
This is 193 MiB more data to be accessed than the native filesystem
format, but it needs to come over a much smaller pipe (local Ethernet
typically) than the local SATA disk drive.
I also never got around to writing the "repack" support for the DHT
schema, as it turns out to be fairly complex to safely repack data in
the repository while also trying to minimize the amount of changes
made to the database, due to very common limitations on database
mutation rates..
This new DFS storage layer fixes a lot of those issues by taking the
simple approach for storing relatively standard Git pack and index
files on an abstract filesystem. Packs are accessed by an in-process
buffer cache, similar to the WindowCache used by the local filesystem
storage layer. Unlike the local file IO, there are some assumptions
that the storage system has relatively high latency and no concept of
"file handles". Instead it looks at the file more like HTTP byte range
requests, where a read channel is a simply a thunk to trigger a read
request over the network.
The DFS code in this change is still abstract, it does not store on
any particular filesystem, but is fairly well suited to the Amazon S3
or Apache Hadoop HDFS. Storing packs directly on HDFS rather than
HBase removes a layer of abstraction, as most HBase row reads turn
into an HDFS read.
Most of the DFS code in this change was blatently copied from the
local filesystem code. Most parts should be refactored to be shared
between the two storage systems, but right now I am hesistent to do
this due to how well tuned the local filesystem code currently is.
Change-Id: Iec524abdf172e9ec5485d6c88ca6512cd8a6eafb
vor 13 Jahren DFS: A storage layer for JGit
In practice the DHT storage layer has not been performing as well as
large scale server environments want to see from a Git server.
The performance of the DHT schema degrades rapidly as small changes
are pushed into the repository due to the chunk size being less than
1/3 of the pushed pack size. Small chunks cause poor prefetch
performance during reading, and require significantly longer prefetch
lists inside of the chunk meta field to work around the small size.
The DHT code is very complex (>17,000 lines of code) and is very
sensitive to the underlying database round-trip time, as well as the
way objects were written into the pack stream that was chunked and
stored on the database. A poor pack layout (from any version of C Git
prior to Junio reworking it) can cause the DHT code to be unable to
enumerate the objects of the linux-2.6 repository in a completable
time scale.
Performing a clone from a DHT stored repository of 2 million objects
takes 2 million row lookups in the DHT to locate the OBJECT_INDEX row
for each object being cloned. This is very difficult for some DHTs to
scale, even at 5000 rows/second the lookup stage alone takes 6 minutes
(on local filesystem, this is almost too fast to bother measuring).
Some servers like Apache Cassandra just fall over and cannot complete
the 2 million lookups in rapid fire.
On a ~400 MiB repository, the DHT schema has an extra 25 MiB of
redundant data that gets downloaded to the JGit process, and that is
before you consider the cost of the OBJECT_INDEX table also being
fully loaded, which is at least 223 MiB of data for the linux kernel
repository. In the DHT schema answering a `git clone` of the ~400 MiB
linux kernel needs to load 248 MiB of "index" data from the DHT, in
addition to the ~400 MiB of pack data that gets sent to the client.
This is 193 MiB more data to be accessed than the native filesystem
format, but it needs to come over a much smaller pipe (local Ethernet
typically) than the local SATA disk drive.
I also never got around to writing the "repack" support for the DHT
schema, as it turns out to be fairly complex to safely repack data in
the repository while also trying to minimize the amount of changes
made to the database, due to very common limitations on database
mutation rates..
This new DFS storage layer fixes a lot of those issues by taking the
simple approach for storing relatively standard Git pack and index
files on an abstract filesystem. Packs are accessed by an in-process
buffer cache, similar to the WindowCache used by the local filesystem
storage layer. Unlike the local file IO, there are some assumptions
that the storage system has relatively high latency and no concept of
"file handles". Instead it looks at the file more like HTTP byte range
requests, where a read channel is a simply a thunk to trigger a read
request over the network.
The DFS code in this change is still abstract, it does not store on
any particular filesystem, but is fairly well suited to the Amazon S3
or Apache Hadoop HDFS. Storing packs directly on HDFS rather than
HBase removes a layer of abstraction, as most HBase row reads turn
into an HDFS read.
Most of the DFS code in this change was blatently copied from the
local filesystem code. Most parts should be refactored to be shared
between the two storage systems, but right now I am hesistent to do
this due to how well tuned the local filesystem code currently is.
Change-Id: Iec524abdf172e9ec5485d6c88ca6512cd8a6eafb
vor 13 Jahren DFS: A storage layer for JGit
In practice the DHT storage layer has not been performing as well as
large scale server environments want to see from a Git server.
The performance of the DHT schema degrades rapidly as small changes
are pushed into the repository due to the chunk size being less than
1/3 of the pushed pack size. Small chunks cause poor prefetch
performance during reading, and require significantly longer prefetch
lists inside of the chunk meta field to work around the small size.
The DHT code is very complex (>17,000 lines of code) and is very
sensitive to the underlying database round-trip time, as well as the
way objects were written into the pack stream that was chunked and
stored on the database. A poor pack layout (from any version of C Git
prior to Junio reworking it) can cause the DHT code to be unable to
enumerate the objects of the linux-2.6 repository in a completable
time scale.
Performing a clone from a DHT stored repository of 2 million objects
takes 2 million row lookups in the DHT to locate the OBJECT_INDEX row
for each object being cloned. This is very difficult for some DHTs to
scale, even at 5000 rows/second the lookup stage alone takes 6 minutes
(on local filesystem, this is almost too fast to bother measuring).
Some servers like Apache Cassandra just fall over and cannot complete
the 2 million lookups in rapid fire.
On a ~400 MiB repository, the DHT schema has an extra 25 MiB of
redundant data that gets downloaded to the JGit process, and that is
before you consider the cost of the OBJECT_INDEX table also being
fully loaded, which is at least 223 MiB of data for the linux kernel
repository. In the DHT schema answering a `git clone` of the ~400 MiB
linux kernel needs to load 248 MiB of "index" data from the DHT, in
addition to the ~400 MiB of pack data that gets sent to the client.
This is 193 MiB more data to be accessed than the native filesystem
format, but it needs to come over a much smaller pipe (local Ethernet
typically) than the local SATA disk drive.
I also never got around to writing the "repack" support for the DHT
schema, as it turns out to be fairly complex to safely repack data in
the repository while also trying to minimize the amount of changes
made to the database, due to very common limitations on database
mutation rates..
This new DFS storage layer fixes a lot of those issues by taking the
simple approach for storing relatively standard Git pack and index
files on an abstract filesystem. Packs are accessed by an in-process
buffer cache, similar to the WindowCache used by the local filesystem
storage layer. Unlike the local file IO, there are some assumptions
that the storage system has relatively high latency and no concept of
"file handles". Instead it looks at the file more like HTTP byte range
requests, where a read channel is a simply a thunk to trigger a read
request over the network.
The DFS code in this change is still abstract, it does not store on
any particular filesystem, but is fairly well suited to the Amazon S3
or Apache Hadoop HDFS. Storing packs directly on HDFS rather than
HBase removes a layer of abstraction, as most HBase row reads turn
into an HDFS read.
Most of the DFS code in this change was blatently copied from the
local filesystem code. Most parts should be refactored to be shared
between the two storage systems, but right now I am hesistent to do
this due to how well tuned the local filesystem code currently is.
Change-Id: Iec524abdf172e9ec5485d6c88ca6512cd8a6eafb
vor 13 Jahren DFS: A storage layer for JGit
In practice the DHT storage layer has not been performing as well as
large scale server environments want to see from a Git server.
The performance of the DHT schema degrades rapidly as small changes
are pushed into the repository due to the chunk size being less than
1/3 of the pushed pack size. Small chunks cause poor prefetch
performance during reading, and require significantly longer prefetch
lists inside of the chunk meta field to work around the small size.
The DHT code is very complex (>17,000 lines of code) and is very
sensitive to the underlying database round-trip time, as well as the
way objects were written into the pack stream that was chunked and
stored on the database. A poor pack layout (from any version of C Git
prior to Junio reworking it) can cause the DHT code to be unable to
enumerate the objects of the linux-2.6 repository in a completable
time scale.
Performing a clone from a DHT stored repository of 2 million objects
takes 2 million row lookups in the DHT to locate the OBJECT_INDEX row
for each object being cloned. This is very difficult for some DHTs to
scale, even at 5000 rows/second the lookup stage alone takes 6 minutes
(on local filesystem, this is almost too fast to bother measuring).
Some servers like Apache Cassandra just fall over and cannot complete
the 2 million lookups in rapid fire.
On a ~400 MiB repository, the DHT schema has an extra 25 MiB of
redundant data that gets downloaded to the JGit process, and that is
before you consider the cost of the OBJECT_INDEX table also being
fully loaded, which is at least 223 MiB of data for the linux kernel
repository. In the DHT schema answering a `git clone` of the ~400 MiB
linux kernel needs to load 248 MiB of "index" data from the DHT, in
addition to the ~400 MiB of pack data that gets sent to the client.
This is 193 MiB more data to be accessed than the native filesystem
format, but it needs to come over a much smaller pipe (local Ethernet
typically) than the local SATA disk drive.
I also never got around to writing the "repack" support for the DHT
schema, as it turns out to be fairly complex to safely repack data in
the repository while also trying to minimize the amount of changes
made to the database, due to very common limitations on database
mutation rates..
This new DFS storage layer fixes a lot of those issues by taking the
simple approach for storing relatively standard Git pack and index
files on an abstract filesystem. Packs are accessed by an in-process
buffer cache, similar to the WindowCache used by the local filesystem
storage layer. Unlike the local file IO, there are some assumptions
that the storage system has relatively high latency and no concept of
"file handles". Instead it looks at the file more like HTTP byte range
requests, where a read channel is a simply a thunk to trigger a read
request over the network.
The DFS code in this change is still abstract, it does not store on
any particular filesystem, but is fairly well suited to the Amazon S3
or Apache Hadoop HDFS. Storing packs directly on HDFS rather than
HBase removes a layer of abstraction, as most HBase row reads turn
into an HDFS read.
Most of the DFS code in this change was blatently copied from the
local filesystem code. Most parts should be refactored to be shared
between the two storage systems, but right now I am hesistent to do
this due to how well tuned the local filesystem code currently is.
Change-Id: Iec524abdf172e9ec5485d6c88ca6512cd8a6eafb
vor 13 Jahren Run auto GC in the background
When running an automatic GC on a FileRepository, when the caller
passes a NullProgressMonitor, run the GC in a background thread. Use a
thread pool of size 1 to limit the number of background threads spawned
for background gc in the same application. In the next minor release we
can make the thread pool configurable.
In some cases, the auto GC limit is lower than the true number of
unreachable loose objects, so auto GC will run after every (e.g) fetch
operation. This leads to the appearance of poor fetch performance.
Since these GCs will never make progress (until either the objects
become referenced, or the two week timeout expires), blocking on them
simply reduces throughput.
In the event that an auto GC would make progress, it's still OK if it
runs in the background. The progress will still happen.
This matches the behavior of regular git.
Git (and now jgit) uses the lock file for gc.log to prevent simultaneous
runs of background gc. Further, it writes errors to gc.log, and won't
run background gc if that file is present and recent. If gc.log is too
old (according to the config gc.logexpiry), it will be ignored.
Change-Id: I3870cadb4a0a6763feff252e6eaef99f4aa8d0df
Signed-off-by: David Turner <dturner@twosigma.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> vor 7 Jahren |
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761 |
- /*
- * Copyright (C) 2010, Mathias Kinzler <mathias.kinzler@sap.com>
- * Copyright (C) 2010, Chris Aniszczyk <caniszczyk@gmail.com>
- * Copyright (C) 2012, 2021, Robin Rosenberg and others
- *
- * This program and the accompanying materials are made available under the
- * terms of the Eclipse Distribution License v. 1.0 which is available at
- * https://www.eclipse.org/org/documents/edl-v10.php.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
- package org.eclipse.jgit.lib;
-
- /**
- * Constants for use with the Configuration classes: section names,
- * configuration keys
- */
- @SuppressWarnings("nls")
- public final class ConfigConstants {
- /** The "core" section */
- public static final String CONFIG_CORE_SECTION = "core";
-
- /** The "branch" section */
- public static final String CONFIG_BRANCH_SECTION = "branch";
-
- /** The "remote" section */
- public static final String CONFIG_REMOTE_SECTION = "remote";
-
- /** The "diff" section */
- public static final String CONFIG_DIFF_SECTION = "diff";
-
- /** The "dfs" section */
- public static final String CONFIG_DFS_SECTION = "dfs";
-
- /**
- * The "receive" section
- * @since 4.6
- */
- public static final String CONFIG_RECEIVE_SECTION = "receive";
-
- /** The "user" section */
- public static final String CONFIG_USER_SECTION = "user";
-
- /** The "gerrit" section */
- public static final String CONFIG_GERRIT_SECTION = "gerrit";
-
- /** The "workflow" section */
- public static final String CONFIG_WORKFLOW_SECTION = "workflow";
-
- /** The "submodule" section */
- public static final String CONFIG_SUBMODULE_SECTION = "submodule";
-
- /**
- * The "rebase" section
- * @since 3.2
- */
- public static final String CONFIG_REBASE_SECTION = "rebase";
-
- /** The "gc" section */
- public static final String CONFIG_GC_SECTION = "gc";
-
- /** The "pack" section */
- public static final String CONFIG_PACK_SECTION = "pack";
-
- /**
- * The "fetch" section
- * @since 3.3
- */
- public static final String CONFIG_FETCH_SECTION = "fetch";
-
- /**
- * The "pull" section
- * @since 3.5
- */
- public static final String CONFIG_PULL_SECTION = "pull";
-
- /**
- * The "merge" section
- * @since 4.9
- */
- public static final String CONFIG_MERGE_SECTION = "merge";
-
- /**
- * The "filter" section
- * @since 4.6
- */
- public static final String CONFIG_FILTER_SECTION = "filter";
-
- /**
- * The "gpg" section
- * @since 5.2
- */
- public static final String CONFIG_GPG_SECTION = "gpg";
-
- /**
- * The "protocol" section
- * @since 5.9
- */
- public static final String CONFIG_PROTOCOL_SECTION = "protocol";
-
- /**
- * The "format" key
- * @since 5.2
- */
- public static final String CONFIG_KEY_FORMAT = "format";
-
- /**
- * The "program" key
- *
- * @since 5.11
- */
- public static final String CONFIG_KEY_PROGRAM = "program";
-
- /**
- * The "signingKey" key
- *
- * @since 5.2
- */
- public static final String CONFIG_KEY_SIGNINGKEY = "signingKey";
-
- /**
- * The "commit" section
- * @since 5.2
- */
- public static final String CONFIG_COMMIT_SECTION = "commit";
-
- /**
- * The "tag" section
- *
- * @since 5.11
- */
- public static final String CONFIG_TAG_SECTION = "tag";
-
- /**
- * The "gpgSign" key
- *
- * @since 5.2
- */
- public static final String CONFIG_KEY_GPGSIGN = "gpgSign";
-
- /**
- * The "forceSignAnnotated" key
- *
- * @since 5.11
- */
- public static final String CONFIG_KEY_FORCE_SIGN_ANNOTATED = "forceSignAnnotated";
-
- /**
- * The "hooksPath" key.
- *
- * @since 5.6
- */
- public static final String CONFIG_KEY_HOOKS_PATH = "hooksPath";
-
- /**
- * The "quotePath" key.
- * @since 5.6
- */
- public static final String CONFIG_KEY_QUOTE_PATH = "quotePath";
-
- /** The "algorithm" key */
- public static final String CONFIG_KEY_ALGORITHM = "algorithm";
-
- /** The "autocrlf" key */
- public static final String CONFIG_KEY_AUTOCRLF = "autocrlf";
-
- /**
- * The "auto" key
- * @since 4.6
- */
- public static final String CONFIG_KEY_AUTO = "auto";
-
- /**
- * The "autogc" key
- * @since 4.6
- */
- public static final String CONFIG_KEY_AUTOGC = "autogc";
-
- /**
- * The "autopacklimit" key
- * @since 4.6
- */
- public static final String CONFIG_KEY_AUTOPACKLIMIT = "autopacklimit";
-
- /**
- * The "eol" key
- *
- * @since 4.3
- */
- public static final String CONFIG_KEY_EOL = "eol";
-
- /** The "bare" key */
- public static final String CONFIG_KEY_BARE = "bare";
-
- /** The "excludesfile" key */
- public static final String CONFIG_KEY_EXCLUDESFILE = "excludesfile";
-
- /**
- * The "attributesfile" key
- *
- * @since 3.7
- */
- public static final String CONFIG_KEY_ATTRIBUTESFILE = "attributesfile";
-
- /** The "filemode" key */
- public static final String CONFIG_KEY_FILEMODE = "filemode";
-
- /** The "logallrefupdates" key */
- public static final String CONFIG_KEY_LOGALLREFUPDATES = "logallrefupdates";
-
- /** The "repositoryformatversion" key */
- public static final String CONFIG_KEY_REPO_FORMAT_VERSION = "repositoryformatversion";
-
- /** The "worktree" key */
- public static final String CONFIG_KEY_WORKTREE = "worktree";
-
- /** The "blockLimit" key */
- public static final String CONFIG_KEY_BLOCK_LIMIT = "blockLimit";
-
- /** The "blockSize" key */
- public static final String CONFIG_KEY_BLOCK_SIZE = "blockSize";
-
- /**
- * The "concurrencyLevel" key
- *
- * @since 4.6
- */
- public static final String CONFIG_KEY_CONCURRENCY_LEVEL = "concurrencyLevel";
-
- /** The "deltaBaseCacheLimit" key */
- public static final String CONFIG_KEY_DELTA_BASE_CACHE_LIMIT = "deltaBaseCacheLimit";
-
- /**
- * The "symlinks" key
- * @since 3.3
- */
- public static final String CONFIG_KEY_SYMLINKS = "symlinks";
-
- /** The "streamFileThreshold" key */
- public static final String CONFIG_KEY_STREAM_FILE_TRESHOLD = "streamFileThreshold";
-
- /**
- * The "packedGitMmap" key
- * @since 5.1.13
- */
- public static final String CONFIG_KEY_PACKED_GIT_MMAP = "packedgitmmap";
-
- /**
- * The "packedGitWindowSize" key
- * @since 5.1.13
- */
- public static final String CONFIG_KEY_PACKED_GIT_WINDOWSIZE = "packedgitwindowsize";
-
- /**
- * The "packedGitLimit" key
- * @since 5.1.13
- */
- public static final String CONFIG_KEY_PACKED_GIT_LIMIT = "packedgitlimit";
-
- /**
- * The "packedGitOpenFiles" key
- * @since 5.1.13
- */
- public static final String CONFIG_KEY_PACKED_GIT_OPENFILES = "packedgitopenfiles";
-
- /**
- * The "packedGitUseStrongRefs" key
- * @since 5.1.13
- */
- public static final String CONFIG_KEY_PACKED_GIT_USE_STRONGREFS = "packedgitusestrongrefs";
-
- /** The "remote" key */
- public static final String CONFIG_KEY_REMOTE = "remote";
-
- /** The "merge" key */
- public static final String CONFIG_KEY_MERGE = "merge";
-
- /** The "rebase" key */
- public static final String CONFIG_KEY_REBASE = "rebase";
-
- /** The "url" key */
- public static final String CONFIG_KEY_URL = "url";
-
- /** The "autosetupmerge" key */
- public static final String CONFIG_KEY_AUTOSETUPMERGE = "autosetupmerge";
-
- /** The "autosetuprebase" key */
- public static final String CONFIG_KEY_AUTOSETUPREBASE = "autosetuprebase";
-
- /**
- * The "autostash" key
- * @since 3.2
- */
- public static final String CONFIG_KEY_AUTOSTASH = "autostash";
-
- /** The "name" key */
- public static final String CONFIG_KEY_NAME = "name";
-
- /** The "email" key */
- public static final String CONFIG_KEY_EMAIL = "email";
-
- /** The "false" key (used to configure {@link #CONFIG_KEY_AUTOSETUPMERGE} */
- public static final String CONFIG_KEY_FALSE = "false";
-
- /** The "true" key (used to configure {@link #CONFIG_KEY_AUTOSETUPMERGE} */
- public static final String CONFIG_KEY_TRUE = "true";
-
- /**
- * The "always" key (used to configure {@link #CONFIG_KEY_AUTOSETUPREBASE}
- * and {@link #CONFIG_KEY_AUTOSETUPMERGE}
- */
- public static final String CONFIG_KEY_ALWAYS = "always";
-
- /** The "never" key (used to configure {@link #CONFIG_KEY_AUTOSETUPREBASE} */
- public static final String CONFIG_KEY_NEVER = "never";
-
- /** The "local" key (used to configure {@link #CONFIG_KEY_AUTOSETUPREBASE} */
- public static final String CONFIG_KEY_LOCAL = "local";
-
- /** The "createchangeid" key */
- public static final String CONFIG_KEY_CREATECHANGEID = "createchangeid";
-
- /** The "defaultsourceref" key */
- public static final String CONFIG_KEY_DEFBRANCHSTARTPOINT = "defbranchstartpoint";
-
- /** The "path" key */
- public static final String CONFIG_KEY_PATH = "path";
-
- /** The "update" key */
- public static final String CONFIG_KEY_UPDATE = "update";
-
- /**
- * The "ignore" key
- * @since 3.6
- */
- public static final String CONFIG_KEY_IGNORE = "ignore";
-
- /** The "compression" key */
- public static final String CONFIG_KEY_COMPRESSION = "compression";
-
- /** The "indexversion" key */
- public static final String CONFIG_KEY_INDEXVERSION = "indexversion";
-
- /**
- * The "hidedotfiles" key
- * @since 3.5
- */
- public static final String CONFIG_KEY_HIDEDOTFILES = "hidedotfiles";
-
- /**
- * The "dirnogitlinks" key
- * @since 4.3
- */
- public static final String CONFIG_KEY_DIRNOGITLINKS = "dirNoGitLinks";
-
- /** The "precomposeunicode" key */
- public static final String CONFIG_KEY_PRECOMPOSEUNICODE = "precomposeunicode";
-
- /** The "pruneexpire" key */
- public static final String CONFIG_KEY_PRUNEEXPIRE = "pruneexpire";
-
- /**
- * The "prunepackexpire" key
- * @since 4.3
- */
- public static final String CONFIG_KEY_PRUNEPACKEXPIRE = "prunepackexpire";
-
- /**
- * The "logexpiry" key
- *
- * @since 4.7
- */
- public static final String CONFIG_KEY_LOGEXPIRY = "logExpiry";
-
- /**
- * The "autodetach" key
- *
- * @since 4.7
- */
- public static final String CONFIG_KEY_AUTODETACH = "autoDetach";
-
- /**
- * The "aggressiveDepth" key
- * @since 3.6
- */
- public static final String CONFIG_KEY_AGGRESSIVE_DEPTH = "aggressiveDepth";
-
- /**
- * The "aggressiveWindow" key
- * @since 3.6
- */
- public static final String CONFIG_KEY_AGGRESSIVE_WINDOW = "aggressiveWindow";
-
- /** The "mergeoptions" key */
- public static final String CONFIG_KEY_MERGEOPTIONS = "mergeoptions";
-
- /** The "ff" key */
- public static final String CONFIG_KEY_FF = "ff";
-
- /**
- * The "conflictStyle" key.
- *
- * @since 5.12
- */
- public static final String CONFIG_KEY_CONFLICTSTYLE = "conflictStyle";
-
- /**
- * The "checkstat" key
- *
- * @since 3.0
- */
- public static final String CONFIG_KEY_CHECKSTAT = "checkstat";
-
- /**
- * The "renamelimit" key in the "diff" section
- * @since 3.0
- */
- public static final String CONFIG_KEY_RENAMELIMIT = "renamelimit";
-
- /**
- * The "trustfolderstat" key in the "core" section
- * @since 3.6
- */
- public static final String CONFIG_KEY_TRUSTFOLDERSTAT = "trustfolderstat";
-
- /**
- * The "supportsAtomicFileCreation" key in the "core" section
- *
- * @since 4.5
- */
- public static final String CONFIG_KEY_SUPPORTSATOMICFILECREATION = "supportsatomicfilecreation";
-
- /**
- * The "noprefix" key in the "diff" section
- * @since 3.0
- */
- public static final String CONFIG_KEY_NOPREFIX = "noprefix";
-
- /**
- * A "renamelimit" value in the "diff" section
- * @since 3.0
- */
- public static final String CONFIG_RENAMELIMIT_COPY = "copy";
-
- /**
- * A "renamelimit" value in the "diff" section
- * @since 3.0
- */
- public static final String CONFIG_RENAMELIMIT_COPIES = "copies";
-
- /**
- * The "renames" key in the "diff" section
- * @since 3.0
- */
- public static final String CONFIG_KEY_RENAMES = "renames";
-
- /**
- * The "inCoreLimit" key in the "merge" section. It's a size limit (bytes) used to
- * control a file to be stored in {@code Heap} or {@code LocalFile} during the merge.
- * @since 4.9
- */
- public static final String CONFIG_KEY_IN_CORE_LIMIT = "inCoreLimit";
-
- /**
- * The "prune" key
- * @since 3.3
- */
- public static final String CONFIG_KEY_PRUNE = "prune";
-
- /**
- * The "streamBuffer" key
- * @since 4.0
- */
- public static final String CONFIG_KEY_STREAM_BUFFER = "streamBuffer";
-
- /**
- * The "streamRatio" key
- * @since 4.0
- */
- public static final String CONFIG_KEY_STREAM_RATIO = "streamRatio";
-
- /**
- * Flag in the filter section whether to use JGit's implementations of
- * filters and hooks
- * @since 4.6
- */
- public static final String CONFIG_KEY_USEJGITBUILTIN = "useJGitBuiltin";
-
- /**
- * The "fetchRecurseSubmodules" key
- * @since 4.7
- */
- public static final String CONFIG_KEY_FETCH_RECURSE_SUBMODULES = "fetchRecurseSubmodules";
-
- /**
- * The "recurseSubmodules" key
- * @since 4.7
- */
- public static final String CONFIG_KEY_RECURSE_SUBMODULES = "recurseSubmodules";
-
- /**
- * The "required" key
- * @since 4.11
- */
- public static final String CONFIG_KEY_REQUIRED = "required";
-
- /**
- * The "lfs" section
- * @since 4.11
- */
- public static final String CONFIG_SECTION_LFS = "lfs";
-
- /**
- * The "i18n" section
- *
- * @since 5.2
- */
- public static final String CONFIG_SECTION_I18N = "i18n";
-
- /**
- * The "logOutputEncoding" key
- *
- * @since 5.2
- */
- public static final String CONFIG_KEY_LOG_OUTPUT_ENCODING = "logOutputEncoding";
-
- /**
- * The "filesystem" section
- * @since 5.1.9
- */
- public static final String CONFIG_FILESYSTEM_SECTION = "filesystem";
-
- /**
- * The "timestampResolution" key
- * @since 5.1.9
- */
- public static final String CONFIG_KEY_TIMESTAMP_RESOLUTION = "timestampResolution";
-
- /**
- * The "minRacyThreshold" key
- * @since 5.1.9
- */
- public static final String CONFIG_KEY_MIN_RACY_THRESHOLD = "minRacyThreshold";
-
-
- /**
- * The "refStorage" key
- *
- * @since 5.6.2
- */
- public static final String CONFIG_KEY_REF_STORAGE = "refStorage";
-
- /**
- * The "extensions" section
- *
- * @since 5.6.2
- */
- public static final String CONFIG_EXTENSIONS_SECTION = "extensions";
-
- /**
- * The extensions.refStorage key
- * @since 5.7
- */
- public static final String CONFIG_KEY_REFSTORAGE = "refStorage";
-
- /**
- * The "reftable" refStorage format
- * @since 5.7
- */
- public static final String CONFIG_REF_STORAGE_REFTABLE = "reftable";
-
- /**
- * The "jmx" section
- * @since 5.1.13
- */
- public static final String CONFIG_JMX_SECTION = "jmx";
-
- /**
- * The "pack.bigfilethreshold" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BIGFILE_THRESHOLD = "bigfilethreshold";
-
- /**
- * The "pack.bitmapContiguousCommitCount" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BITMAP_CONTIGUOUS_COMMIT_COUNT = "bitmapcontiguouscommitcount";
-
- /**
- * The "pack.bitmapDistantCommitSpan" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BITMAP_DISTANT_COMMIT_SPAN = "bitmapdistantcommitspan";
-
- /**
- * The "pack.bitmapExcessiveBranchCount" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BITMAP_EXCESSIVE_BRANCH_COUNT = "bitmapexcessivebranchcount";
-
- /**
- * The "pack.bitmapInactiveBranchAgeInDays" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BITMAP_INACTIVE_BRANCH_AGE_INDAYS = "bitmapinactivebranchageindays";
-
- /**
- * The "pack.bitmapRecentCommitSpan" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BITMAP_RECENT_COMMIT_COUNT = "bitmaprecentcommitspan";
-
- /**
- * The "pack.buildBitmaps" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_BUILD_BITMAPS = "buildbitmaps";
-
- /**
- * The "pack.cutDeltaChains" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_CUT_DELTACHAINS = "cutdeltachains";
-
- /**
- * The "pack.deltaCacheLimit" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_DELTA_CACHE_LIMIT = "deltacachelimit";
-
- /**
- * The "pack.deltaCacheSize" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_DELTA_CACHE_SIZE = "deltacachesize";
-
- /**
- * The "pack.deltaCompression" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_DELTA_COMPRESSION = "deltacompression";
-
- /**
- * The "pack.depth" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_DEPTH = "depth";
-
- /**
- * The "pack.minSizePreventRacyPack" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_MIN_SIZE_PREVENT_RACYPACK = "minsizepreventracypack";
-
- /**
- * The "pack.reuseDeltas" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_REUSE_DELTAS = "reusedeltas";
-
- /**
- * The "pack.reuseObjects" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_REUSE_OBJECTS = "reuseobjects";
-
- /**
- * The "pack.singlePack" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_SINGLE_PACK = "singlepack";
-
- /**
- * The "pack.threads" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_THREADS = "threads";
-
- /**
- * The "pack.waitPreventRacyPack" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_WAIT_PREVENT_RACYPACK = "waitpreventracypack";
-
- /**
- * The "pack.window" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_WINDOW = "window";
-
- /**
- * The "pack.windowMemory" key
- * @since 5.8
- */
- public static final String CONFIG_KEY_WINDOW_MEMORY = "windowmemory";
-
- /**
- * The "feature" section
- *
- * @since 5.9
- */
- public static final String CONFIG_FEATURE_SECTION = "feature";
-
- /**
- * The "feature.manyFiles" key
- *
- * @since 5.9
- */
- public static final String CONFIG_KEY_MANYFILES = "manyFiles";
-
- /**
- * The "index" section
- *
- * @since 5.9
- */
- public static final String CONFIG_INDEX_SECTION = "index";
-
- /**
- * The "version" key
- *
- * @since 5.9
- */
- public static final String CONFIG_KEY_VERSION = "version";
-
- /**
- * The "init" section
- *
- * @since 5.11
- */
- public static final String CONFIG_INIT_SECTION = "init";
-
- /**
- * The "defaultBranch" key
- *
- * @since 5.11
- */
- public static final String CONFIG_KEY_DEFAULT_BRANCH = "defaultbranch";
-
- /**
- * The "pack.searchForReuseTimeout" key
- *
- * @since 5.13
- */
- public static final String CONFIG_KEY_SEARCH_FOR_REUSE_TIMEOUT = "searchforreusetimeout";
-
- /**
- * The "commitGraph" section
- *
- * @since 5.13
- */
- public static final String CONFIG_COMMIT_GRAPH_SECTION = "commitGraph";
-
- /**
- * The "computeGeneration" key
- *
- * @since 5.13
- */
- public static final String CONFIG_KEY_COMPUTE_GENERATION = "computeGeneration";
-
- }
|