| 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.fsckObjects`:: |
| 14 | If it is set to true, git-fetch-pack will check all fetched |
| 15 | objects. See `transfer.fsckObjects` for what's |
| 16 | checked. Defaults to `false`. If not set, the value of |
| 17 | `transfer.fsckObjects` is used instead. |
| 18 | |
| 19 | `fetch.fsck.<msg-id>`:: |
| 20 | Acts like `fsck.<msg-id>`, but is used by |
| 21 | linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See |
| 22 | the `fsck.<msg-id>` documentation for details. |
| 23 | |
| 24 | `fetch.fsck.skipList`:: |
| 25 | Acts like `fsck.skipList`, but is used by |
| 26 | linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See |
| 27 | the `fsck.skipList` documentation for details. |
| 28 | |
| 29 | `fetch.unpackLimit`:: |
| 30 | If the number of objects fetched over the Git native |
| 31 | transfer is below this |
| 32 | limit, then the objects will be unpacked into loose object |
| 33 | files. However if the number of received objects equals or |
| 34 | exceeds this limit then the received pack will be stored as |
| 35 | a pack, after adding any missing delta bases. Storing the |
| 36 | pack from a push can make the push operation complete faster, |
| 37 | especially on slow filesystems. If not set, the value of |
| 38 | `transfer.unpackLimit` is used instead. |
| 39 | |
| 40 | `fetch.prune`:: |
| 41 | If true, fetch will automatically behave as if the `--prune` |
| 42 | option was given on the command line. See also `remote.<name>.prune` |
| 43 | and the PRUNING section of linkgit:git-fetch[1]. |
| 44 | |
| 45 | `fetch.pruneTags`:: |
| 46 | If true, fetch will automatically behave as if the |
| 47 | `refs/tags/*:refs/tags/*` refspec was provided when pruning, |
| 48 | if not set already. This allows for setting both this option |
| 49 | and `fetch.prune` to maintain a 1=1 mapping to upstream |
| 50 | refs. See also `remote.<name>.pruneTags` and the PRUNING |
| 51 | section of linkgit:git-fetch[1]. |
| 52 | |
| 53 | `fetch.all`:: |
| 54 | If true, fetch will attempt to update all available remotes. |
| 55 | This behavior can be overridden by passing `--no-all` or by |
| 56 | explicitly specifying one or more remote(s) to fetch from. |
| 57 | Defaults to `false`. |
| 58 | |
| 59 | `fetch.output`:: |
| 60 | Control how ref update status is printed. Valid values are |
| 61 | `full` and `compact`. Default value is `full`. See the |
| 62 | OUTPUT section in linkgit:git-fetch[1] for details. |
| 63 | |
| 64 | `fetch.negotiationAlgorithm`:: |
| 65 | Control how information about the commits in the local repository |
| 66 | is sent when negotiating the contents of the packfile to be sent by |
| 67 | the server. Set to `consecutive` to use an algorithm that walks |
| 68 | over consecutive commits checking each one. Set to `skipping` to |
| 69 | use an algorithm that skips commits in an effort to converge |
| 70 | faster, but may result in a larger-than-necessary packfile; or set |
| 71 | to `noop` to not send any information at all, which will almost |
| 72 | certainly result in a larger-than-necessary packfile, but will skip |
| 73 | the negotiation step. Set to `default` to override settings made |
| 74 | previously and use the default behaviour. The default is normally |
| 75 | `consecutive`, but if `feature.experimental` is `true`, then the |
| 76 | default is `skipping`. Unknown values will cause `git fetch` to |
| 77 | error out. |
| 78 | + |
| 79 | See also the `--negotiate-only` and `--negotiation-restrict` options to |
| 80 | linkgit:git-fetch[1]. |
| 81 | |
| 82 | `fetch.showForcedUpdates`:: |
| 83 | Set to `false` to enable `--no-show-forced-updates` in |
| 84 | linkgit:git-fetch[1] and linkgit:git-pull[1] commands. |
| 85 | Defaults to `true`. |
| 86 | |
| 87 | `fetch.parallel`:: |
| 88 | Specifies the maximal number of fetch operations to be run in parallel |
| 89 | at a time (submodules, or remotes when the `--multiple` option of |
| 90 | linkgit:git-fetch[1] is in effect). |
| 91 | + |
| 92 | A value of 0 will give some reasonable default. If unset, it defaults to 1. |
| 93 | + |
| 94 | For submodules, this setting can be overridden using the `submodule.fetchJobs` |
| 95 | config setting. |
| 96 | |
| 97 | `fetch.writeCommitGraph`:: |
| 98 | Set to true to write a commit-graph after every `git fetch` command |
| 99 | that downloads a pack-file from a remote. Using the `--split` option, |
| 100 | most executions will create a very small commit-graph file on top of |
| 101 | the existing commit-graph file(s). Occasionally, these files will |
| 102 | merge and the write may take longer. Having an updated commit-graph |
| 103 | file helps performance of many Git commands, including `git merge-base`, |
| 104 | `git push -f`, and `git log --graph`. Defaults to `false`. |
| 105 | |
| 106 | `fetch.bundleURI`:: |
| 107 | This value stores a URI for downloading Git object data from a bundle |
| 108 | URI before performing an incremental fetch from the origin Git server. |
| 109 | This is similar to how the `--bundle-uri` option behaves in |
| 110 | linkgit:git-clone[1]. `git clone --bundle-uri` will set the |
| 111 | `fetch.bundleURI` value if the supplied bundle URI contains a bundle |
| 112 | list that is organized for incremental fetches. |
| 113 | + |
| 114 | If you modify this value and your repository has a `fetch.bundleCreationToken` |
| 115 | value, then remove that `fetch.bundleCreationToken` value before fetching from |
| 116 | the new bundle URI. |
| 117 | |
| 118 | `fetch.bundleCreationToken`:: |
| 119 | When using `fetch.bundleURI` to fetch incrementally from a bundle |
| 120 | list that uses the "`creationToken`" heuristic, this config value |
| 121 | stores the maximum `creationToken` value of the downloaded bundles. |
| 122 | This value is used to prevent downloading bundles in the future |
| 123 | if the advertised `creationToken` is not strictly larger than this |
| 124 | value. |
| 125 | + |
| 126 | The creation token values are chosen by the provider serving the specific |
| 127 | bundle URI. If you modify the URI at `fetch.bundleURI`, then be sure to |
| 128 | remove the value for the `fetch.bundleCreationToken` value before fetching. |