| 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 | -- |