b5651a2092
The fetch.writeCommitGraph feature makes fetches write out a commit graph file for the newly downloaded pack on fetch. This improves the performance of various commands that would perform a revision walk and eventually ought to be the default for everyone. To prepare for that future, it's enabled by default for users that set feature.experimental=true to experience such future defaults. Alas, for --unshallow fetches from a shallow clone it runs into a snag: by the time Git has fetched the new objects and is writing a commit graph, it has performed a revision walk and r->parsed_objects contains information about the shallow boundary from *before* the fetch. The commit graph writing code is careful to avoid writing a commit graph file in shallow repositories, but the new state is not shallow, and the result is that from that point on, commands like "git log" make use of a newly written commit graph file representing a fictional history with the old shallow boundary. We could fix this by making the commit graph writing code more careful to avoid writing a commit graph that could have used any grafts or shallow state, but it is possible that there are other pieces of mutated state that fetch's commit graph writing code may be relying on. So disable it in the feature.experimental configuration. Google developers have been running in this configuration (by setting fetch.writeCommitGraph=false in the system config) to work around this bug since it was discovered in April. Once the fix lands, we'll enable fetch.writeCommitGraph=true again to give it some early testing before rolling out to a wider audience. In other words: - this patch only affects behavior with feature.experimental=true - it makes feature.experimental match the configuration Google has been using for the last few months, meaning it would leave users in a better tested state than without it - this should improve testing for other features guarded by feature.experimental, by making feature.experimental safer to use Reported-by: Jay Conrod <jayconrod@google.com> Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
31 lines
1.4 KiB
Plaintext
31 lines
1.4 KiB
Plaintext
feature.*::
|
|
The config settings that start with `feature.` modify the defaults of
|
|
a group of other config settings. These groups are created by the Git
|
|
developer community as recommended defaults and are subject to change.
|
|
In particular, new config options may be added with different defaults.
|
|
|
|
feature.experimental::
|
|
Enable config options that are new to Git, and are being considered for
|
|
future defaults. Config settings included here may be added or removed
|
|
with each release, including minor version updates. These settings may
|
|
have unintended interactions since they are so new. Please enable this
|
|
setting if you are interested in providing feedback on experimental
|
|
features. The new default values are:
|
|
+
|
|
* `fetch.negotiationAlgorithm=skipping` may improve fetch negotiation times by
|
|
skipping more commits at a time, reducing the number of round trips.
|
|
+
|
|
* `protocol.version=2` speeds up fetches from repositories with many refs by
|
|
allowing the client to specify which refs to list before the server lists
|
|
them.
|
|
|
|
feature.manyFiles::
|
|
Enable config options that optimize for repos with many files in the
|
|
working directory. With many files, commands such as `git status` and
|
|
`git checkout` may be slow and these new defaults improve performance:
|
|
+
|
|
* `index.version=4` enables path-prefix compression in the index.
|
|
+
|
|
* `core.untrackedCache=true` enables the untracked cache. This setting assumes
|
|
that mtime is working on your machine.
|