Raw
1 `fetch.recurseSubmodules`::
2 This option controls whether `git fetch` (and the underlying fetch
3 in `git pull`) will recursively fetch into populated submodules.
4 This option can be set either to a boolean value or to `on-demand`.
5 Setting it to a boolean changes the behavior of fetch and pull to
6 recurse unconditionally into submodules when set to true or to not
7 recurse at all when set to false. When set to `on-demand`, fetch and
8 pull will only recurse into a populated submodule when its
9 superproject retrieves a commit that updates the submodule's
10 reference.
11 Defaults to `on-demand`, or to the value of `submodule.recurse` if set.
12
13 `fetch.submoduleErrors`::
14 Controls how errors from submodule fetches are handled when
15 `--recurse-submodules` is in effect. When set to `fail` (the default),
16 any submodule fetch error causes the overall `git fetch` or `git pull`
17 to exit with a non-zero status. When set to `warn`, submodule fetch
18 errors are reported to standard error but do not affect the exit
19 status of the command. This is useful when working in repositories
20 where some branches reference submodule commits that are not yet
21 available on the submodule remote, but those commits are not needed
22 for the currently checked-out branch.
23 +
24 The value of this option can be overridden by the `--submodule-errors`
25 option of linkgit:git-fetch[1].
26
27 `fetch.fsckObjects`::
28 If it is set to true, git-fetch-pack will check all fetched
29 objects. See `transfer.fsckObjects` for what's
30 checked. Defaults to `false`. If not set, the value of
31 `transfer.fsckObjects` is used instead.
32
33 `fetch.fsck.<msg-id>`::
34 Acts like `fsck.<msg-id>`, but is used by
35 linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See
36 the `fsck.<msg-id>` documentation for details.
37
38 `fetch.fsck.skipList`::
39 Acts like `fsck.skipList`, but is used by
40 linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See
41 the `fsck.skipList` documentation for details.
42
43 `fetch.unpackLimit`::
44 If the number of objects fetched over the Git native
45 transfer is below this
46 limit, then the objects will be unpacked into loose object
47 files. However if the number of received objects equals or
48 exceeds this limit then the received pack will be stored as
49 a pack, after adding any missing delta bases. Storing the
50 pack from a push can make the push operation complete faster,
51 especially on slow filesystems. If not set, the value of
52 `transfer.unpackLimit` is used instead.
53
54 `fetch.prune`::
55 If true, fetch will automatically behave as if the `--prune`
56 option was given on the command line. See also `remote.<name>.prune`
57 and the PRUNING section of linkgit:git-fetch[1].
58
59 `fetch.pruneTags`::
60 If true, fetch will automatically behave as if the
61 `refs/tags/*:refs/tags/*` refspec was provided when pruning,
62 if not set already. This allows for setting both this option
63 and `fetch.prune` to maintain a 1=1 mapping to upstream
64 refs. See also `remote.<name>.pruneTags` and the PRUNING
65 section of linkgit:git-fetch[1].
66
67 `fetch.all`::
68 If true, fetch will attempt to update all available remotes.
69 This behavior can be overridden by passing `--no-all` or by
70 explicitly specifying one or more remote(s) to fetch from.
71 Defaults to `false`.
72
73 `fetch.output`::
74 Control how ref update status is printed. Valid values are
75 `full` and `compact`. Default value is `full`. See the
76 OUTPUT section in linkgit:git-fetch[1] for details.
77
78 `fetch.negotiationAlgorithm`::
79 Control how information about the commits in the local repository
80 is sent when negotiating the contents of the packfile to be sent by
81 the server. Set to `consecutive` to use an algorithm that walks
82 over consecutive commits checking each one. Set to `skipping` to
83 use an algorithm that skips commits in an effort to converge
84 faster, but may result in a larger-than-necessary packfile; or set
85 to `noop` to not send any information at all, which will almost
86 certainly result in a larger-than-necessary packfile, but will skip
87 the negotiation step. Set to `default` to override settings made
88 previously and use the default behaviour. The default is normally
89 `consecutive`, but if `feature.experimental` is `true`, then the
90 default is `skipping`. Unknown values will cause `git fetch` to
91 error out.
92 +
93 See also the `--negotiate-only` and `--negotiation-restrict` options to
94 linkgit:git-fetch[1].
95
96 `fetch.showForcedUpdates`::
97 Set to `false` to enable `--no-show-forced-updates` in
98 linkgit:git-fetch[1] and linkgit:git-pull[1] commands.
99 Defaults to `true`.
100
101 `fetch.parallel`::
102 Specifies the maximal number of fetch operations to be run in parallel
103 at a time (submodules, or remotes when the `--multiple` option of
104 linkgit:git-fetch[1] is in effect).
105 +
106 A value of 0 will give some reasonable default. If unset, it defaults to 1.
107 +
108 For submodules, this setting can be overridden using the `submodule.fetchJobs`
109 config setting.
110
111 `fetch.writeCommitGraph`::
112 Set to true to write a commit-graph after every `git fetch` command
113 that downloads a pack-file from a remote. Using the `--split` option,
114 most executions will create a very small commit-graph file on top of
115 the existing commit-graph file(s). Occasionally, these files will
116 merge and the write may take longer. Having an updated commit-graph
117 file helps performance of many Git commands, including `git merge-base`,
118 `git push -f`, and `git log --graph`. Defaults to `false`.
119
120 `fetch.bundleURI`::
121 This value stores a URI for downloading Git object data from a bundle
122 URI before performing an incremental fetch from the origin Git server.
123 This is similar to how the `--bundle-uri` option behaves in
124 linkgit:git-clone[1]. `git clone --bundle-uri` will set the
125 `fetch.bundleURI` value if the supplied bundle URI contains a bundle
126 list that is organized for incremental fetches.
127 +
128 If you modify this value and your repository has a `fetch.bundleCreationToken`
129 value, then remove that `fetch.bundleCreationToken` value before fetching from
130 the new bundle URI.
131
132 `fetch.bundleCreationToken`::
133 When using `fetch.bundleURI` to fetch incrementally from a bundle
134 list that uses the "`creationToken`" heuristic, this config value
135 stores the maximum `creationToken` value of the downloaded bundles.
136 This value is used to prevent downloading bundles in the future
137 if the advertised `creationToken` is not strictly larger than this
138 value.
139 +
140 The creation token values are chosen by the provider serving the specific
141 bundle URI. If you modify the URI at `fetch.bundleURI`, then be sure to
142 remove the value for the `fetch.bundleCreationToken` value before fetching.
143
144 `fetch.followRemoteHEAD`::
145 When fetching using a default refspec, this setting determines how to handle
146 differences between a fetched remote's `HEAD` and the local
147 `remotes/<name>/HEAD` symbolic-ref. Its value is one of
148 +
149 --
150 `create`;;
151 Create `remotes/<name>/HEAD` if a ref exists on the remote, but not locally.
152 An existing symbolic-ref will not be touched. This is the default value.
153 `warn`;;
154 Display a warning if the remote advertises a different `HEAD` than what is
155 set locally. Behaves like "create" if the local symbolic-ref doesn't exist.
156 `always`;;
157 Silently update `remotes/<name>/HEAD` whenever the remote advertises a new
158 value.
159 `never`;;
160 Never create or modify the `remotes/<name>/HEAD` symbolic-ref.
161 --