2018-08-22 18:05:56 +02:00
|
|
|
fetch.recurseSubmodules::
|
2020-04-06 15:57:08 +02:00
|
|
|
This option controls whether `git fetch` (and the underlying fetch
|
|
|
|
in `git pull`) will recursively fetch into populated submodules.
|
|
|
|
This option can be set either to a boolean value or to 'on-demand'.
|
2018-08-22 18:05:56 +02:00
|
|
|
Setting it to a boolean changes the behavior of fetch and pull to
|
2020-04-06 15:57:08 +02:00
|
|
|
recurse unconditionally into submodules when set to true or to not
|
|
|
|
recurse at all when set to false. When set to 'on-demand', fetch and
|
|
|
|
pull will only recurse into a populated submodule when its
|
|
|
|
superproject retrieves a commit that updates the submodule's
|
2018-08-22 18:05:56 +02:00
|
|
|
reference.
|
2020-04-06 15:57:08 +02:00
|
|
|
Defaults to 'on-demand', or to the value of 'submodule.recurse' if set.
|
2018-08-22 18:05:56 +02:00
|
|
|
|
|
|
|
fetch.fsckObjects::
|
|
|
|
If it is set to true, git-fetch-pack will check all fetched
|
|
|
|
objects. See `transfer.fsckObjects` for what's
|
|
|
|
checked. Defaults to false. If not set, the value of
|
|
|
|
`transfer.fsckObjects` is used instead.
|
|
|
|
|
|
|
|
fetch.fsck.<msg-id>::
|
|
|
|
Acts like `fsck.<msg-id>`, but is used by
|
|
|
|
linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See
|
|
|
|
the `fsck.<msg-id>` documentation for details.
|
|
|
|
|
|
|
|
fetch.fsck.skipList::
|
|
|
|
Acts like `fsck.skipList`, but is used by
|
|
|
|
linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See
|
|
|
|
the `fsck.skipList` documentation for details.
|
|
|
|
|
|
|
|
fetch.unpackLimit::
|
|
|
|
If the number of objects fetched over the Git native
|
|
|
|
transfer is below this
|
|
|
|
limit, then the objects will be unpacked into loose object
|
|
|
|
files. However if the number of received objects equals or
|
|
|
|
exceeds this limit then the received pack will be stored as
|
|
|
|
a pack, after adding any missing delta bases. Storing the
|
|
|
|
pack from a push can make the push operation complete faster,
|
|
|
|
especially on slow filesystems. If not set, the value of
|
|
|
|
`transfer.unpackLimit` is used instead.
|
|
|
|
|
|
|
|
fetch.prune::
|
|
|
|
If true, fetch will automatically behave as if the `--prune`
|
|
|
|
option was given on the command line. See also `remote.<name>.prune`
|
|
|
|
and the PRUNING section of linkgit:git-fetch[1].
|
|
|
|
|
|
|
|
fetch.pruneTags::
|
|
|
|
If true, fetch will automatically behave as if the
|
|
|
|
`refs/tags/*:refs/tags/*` refspec was provided when pruning,
|
|
|
|
if not set already. This allows for setting both this option
|
|
|
|
and `fetch.prune` to maintain a 1=1 mapping to upstream
|
|
|
|
refs. See also `remote.<name>.pruneTags` and the PRUNING
|
|
|
|
section of linkgit:git-fetch[1].
|
|
|
|
|
|
|
|
fetch.output::
|
|
|
|
Control how ref update status is printed. Valid values are
|
|
|
|
`full` and `compact`. Default value is `full`. See section
|
|
|
|
OUTPUT in linkgit:git-fetch[1] for detail.
|
|
|
|
|
|
|
|
fetch.negotiationAlgorithm::
|
2022-02-02 04:42:40 +01:00
|
|
|
Control how information about the commits in the local repository
|
|
|
|
is sent when negotiating the contents of the packfile to be sent by
|
|
|
|
the server. Set to "consecutive" to use an algorithm that walks
|
|
|
|
over consecutive commits checking each one. Set to "skipping" to
|
|
|
|
use an algorithm that skips commits in an effort to converge
|
|
|
|
faster, but may result in a larger-than-necessary packfile; or set
|
|
|
|
to "noop" to not send any information at all, which will almost
|
|
|
|
certainly result in a larger-than-necessary packfile, but will skip
|
|
|
|
the negotiation step. Set to "default" to override settings made
|
|
|
|
previously and use the default behaviour. The default is normally
|
|
|
|
"consecutive", but if `feature.experimental` is true, then the
|
|
|
|
default is "skipping". Unknown values will cause 'git fetch' to
|
|
|
|
error out.
|
2018-08-22 18:05:56 +02:00
|
|
|
+
|
2021-06-30 18:38:11 +02:00
|
|
|
See also the `--negotiate-only` and `--negotiation-tip` options to
|
|
|
|
linkgit:git-fetch[1].
|
2019-06-18 22:25:26 +02:00
|
|
|
|
|
|
|
fetch.showForcedUpdates::
|
|
|
|
Set to false to enable `--no-show-forced-updates` in
|
|
|
|
linkgit:git-fetch[1] and linkgit:git-pull[1] commands.
|
|
|
|
Defaults to true.
|
2019-09-03 04:22:02 +02:00
|
|
|
|
2019-10-05 20:46:40 +02:00
|
|
|
fetch.parallel::
|
|
|
|
Specifies the maximal number of fetch operations to be run in parallel
|
|
|
|
at a time (submodules, or remotes when the `--multiple` option of
|
|
|
|
linkgit:git-fetch[1] is in effect).
|
|
|
|
+
|
|
|
|
A value of 0 will give some reasonable default. If unset, it defaults to 1.
|
|
|
|
+
|
|
|
|
For submodules, this setting can be overridden using the `submodule.fetchJobs`
|
|
|
|
config setting.
|
2019-10-15 06:48:00 +02:00
|
|
|
|
2019-09-03 04:22:02 +02:00
|
|
|
fetch.writeCommitGraph::
|
|
|
|
Set to true to write a commit-graph after every `git fetch` command
|
|
|
|
that downloads a pack-file from a remote. Using the `--split` option,
|
|
|
|
most executions will create a very small commit-graph file on top of
|
|
|
|
the existing commit-graph file(s). Occasionally, these files will
|
|
|
|
merge and the write may take longer. Having an updated commit-graph
|
|
|
|
file helps performance of many Git commands, including `git merge-base`,
|
experimental: default to fetch.writeCommitGraph=false
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>
2020-07-07 08:20:39 +02:00
|
|
|
`git push -f`, and `git log --graph`. Defaults to false.
|
2023-01-31 14:29:15 +01:00
|
|
|
|
|
|
|
fetch.bundleURI::
|
|
|
|
This value stores a URI for downloading Git object data from a bundle
|
|
|
|
URI before performing an incremental fetch from the origin Git server.
|
|
|
|
This is similar to how the `--bundle-uri` option behaves in
|
|
|
|
linkgit:git-clone[1]. `git clone --bundle-uri` will set the
|
|
|
|
`fetch.bundleURI` value if the supplied bundle URI contains a bundle
|
|
|
|
list that is organized for incremental fetches.
|
2023-01-31 14:29:18 +01:00
|
|
|
+
|
|
|
|
If you modify this value and your repository has a `fetch.bundleCreationToken`
|
|
|
|
value, then remove that `fetch.bundleCreationToken` value before fetching from
|
|
|
|
the new bundle URI.
|
|
|
|
|
|
|
|
fetch.bundleCreationToken::
|
|
|
|
When using `fetch.bundleURI` to fetch incrementally from a bundle
|
|
|
|
list that uses the "creationToken" heuristic, this config value
|
|
|
|
stores the maximum `creationToken` value of the downloaded bundles.
|
|
|
|
This value is used to prevent downloading bundles in the future
|
|
|
|
if the advertised `creationToken` is not strictly larger than this
|
|
|
|
value.
|
|
|
|
+
|
|
|
|
The creation token values are chosen by the provider serving the specific
|
|
|
|
bundle URI. If you modify the URI at `fetch.bundleURI`, then be sure to
|
|
|
|
remove the value for the `fetch.bundleCreationToken` value before fetching.
|