2018-11-20 07:11:47 +01:00
|
|
|
index.recordEndOfIndexEntries::
|
|
|
|
|
Specifies whether the index file should include an "End Of Index
|
|
|
|
|
Entry" section. This reduces index load time on multiprocessor
|
|
|
|
|
machines but produces a message "ignoring EOIE extension" when
|
|
|
|
|
reading the index using Git versions before 2.20. Defaults to
|
index: make index.threads=true enable ieot and eoie
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of turning on threading is respected.
In other words, permit the following configurations:
- index.threads and index.recordOffsetTable unspecified: do not write
the offset table yet (to avoid alarming the user with "ignoring IEOT
extension" messages when an older version of Git accesses the
repository) but do make use of multiple threads to read the index if
the supporting offset table is present.
This can also be requested explicitly by setting index.threads=true,
0, or >1 and index.recordOffsetTable=false.
- index.threads=false or 1: do not write the offset table, and do not
make use of the offset table.
One can set index.recordOffsetTable=false as well, to be more
explicit.
- index.threads=true, 0, or >1 and index.recordOffsetTable unspecified:
write the offset table and make use of threads at read time.
This can also be requested by setting index.threads=true, 0, >1, or
unspecified and index.recordOffsetTable=true.
Fortunately the complication is temporary: once most Git installations
have upgraded to a version with support for the IEOT and EOIE
extensions, we can flip the defaults for index.recordEndOfIndexEntries
and index.recordOffsetTable to true and eliminate the settings.
Helped-by: Ben Peart <benpeart@microsoft.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-20 07:14:26 +01:00
|
|
|
'true' if index.threads has been explicitly enabled, 'false'
|
|
|
|
|
otherwise.
|
2018-11-20 07:11:47 +01:00
|
|
|
|
2018-11-20 07:12:22 +01:00
|
|
|
index.recordOffsetTable::
|
|
|
|
|
Specifies whether the index file should include an "Index Entry
|
|
|
|
|
Offset Table" section. This reduces index load time on
|
|
|
|
|
multiprocessor machines but produces a message "ignoring IEOT
|
|
|
|
|
extension" when reading the index using Git versions before 2.20.
|
index: make index.threads=true enable ieot and eoie
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of turning on threading is respected.
In other words, permit the following configurations:
- index.threads and index.recordOffsetTable unspecified: do not write
the offset table yet (to avoid alarming the user with "ignoring IEOT
extension" messages when an older version of Git accesses the
repository) but do make use of multiple threads to read the index if
the supporting offset table is present.
This can also be requested explicitly by setting index.threads=true,
0, or >1 and index.recordOffsetTable=false.
- index.threads=false or 1: do not write the offset table, and do not
make use of the offset table.
One can set index.recordOffsetTable=false as well, to be more
explicit.
- index.threads=true, 0, or >1 and index.recordOffsetTable unspecified:
write the offset table and make use of threads at read time.
This can also be requested by setting index.threads=true, 0, >1, or
unspecified and index.recordOffsetTable=true.
Fortunately the complication is temporary: once most Git installations
have upgraded to a version with support for the IEOT and EOIE
extensions, we can flip the defaults for index.recordEndOfIndexEntries
and index.recordOffsetTable to true and eliminate the settings.
Helped-by: Ben Peart <benpeart@microsoft.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-20 07:14:26 +01:00
|
|
|
Defaults to 'true' if index.threads has been explicitly enabled,
|
|
|
|
|
'false' otherwise.
|
2018-11-20 07:12:22 +01:00
|
|
|
|
2021-03-30 15:10:59 +02:00
|
|
|
index.sparse::
|
|
|
|
|
When enabled, write the index using sparse-directory entries. This
|
|
|
|
|
has no effect unless `core.sparseCheckout` and
|
|
|
|
|
`core.sparseCheckoutCone` are both enabled. Defaults to 'false'.
|
|
|
|
|
|
2018-10-27 08:23:11 +02:00
|
|
|
index.threads::
|
|
|
|
|
Specifies the number of threads to spawn when loading the index.
|
|
|
|
|
This is meant to reduce index load time on multiprocessor machines.
|
|
|
|
|
Specifying 0 or 'true' will cause Git to auto-detect the number of
|
|
|
|
|
CPU's and set the number of threads accordingly. Specifying 1 or
|
|
|
|
|
'false' will disable multithreading. Defaults to 'true'.
|
|
|
|
|
|
|
|
|
|
index.version::
|
|
|
|
|
Specify the version with which new index files should be
|
|
|
|
|
initialized. This does not affect existing repositories.
|
2019-08-13 20:37:47 +02:00
|
|
|
If `feature.manyFiles` is enabled, then the default is 4.
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
|
|
|
|
|
index.skipHash::
|
|
|
|
|
When enabled, do not compute the trailing hash for the index file.
|
|
|
|
|
This accelerates Git commands that manipulate the index, such as
|
|
|
|
|
`git add`, `git commit`, or `git status`. Instead of storing the
|
|
|
|
|
checksum, write a trailing set of bytes with value zero, indicating
|
|
|
|
|
that the computation was skipped.
|
|
|
|
|
+
|
|
|
|
|
If you enable `index.skipHash`, then Git clients older than 2.13.0 will
|
|
|
|
|
refuse to parse the index and Git clients older than 2.40.0 will report an
|
|
|
|
|
error during `git fsck`.
|