1http.proxy:: 2 Override the HTTP proxy, normally configured using the 'http_proxy', 3 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In 4 addition to the syntax understood by curl, it is possible to specify a 5 proxy string with a user name but no password, in which case git will 6 attempt to acquire one in the same way it does for other credentials. See 7 linkgit:gitcredentials[7] for more information. The syntax thus is 8 '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden 9 on a per-remote basis; see remote.<name>.proxy 10 11http.proxyAuthMethod:: 12 Set the method with which to authenticate against the HTTP proxy. This 13 only takes effect if the configured proxy string contains a user name part 14 (i.e. is of the form 'user@host' or 'user@host:port'). This can be 15 overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`. 16 Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment 17 variable. Possible values are: 18+ 19-- 20* `anyauth` - Automatically pick a suitable authentication method. It is 21 assumed that the proxy answers an unauthenticated request with a 407 22 status code and one or more Proxy-authenticate headers with supported 23 authentication methods. This is the default. 24* `basic` - HTTP Basic authentication 25* `digest` - HTTP Digest authentication; this prevents the password from being 26 transmitted to the proxy in clear text 27* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option 28 of `curl(1)`) 29* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`) 30-- 31 32http.emptyAuth:: 33 Attempt authentication without seeking a username or password. This 34 can be used to attempt GSS-Negotiate authentication without specifying 35 a username in the URL, as libcurl normally requires a username for 36 authentication. 37 38http.delegation:: 39 Control GSSAPI credential delegation. The delegation is disabled 40 by default in libcurl since version 7.21.7. Set parameter to tell 41 the server what it is allowed to delegate when it comes to user 42 credentials. Used with GSS/kerberos. Possible values are: 43+ 44-- 45* `none` - Don't allow any delegation. 46* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the 47 Kerberos service ticket, which is a matter of realm policy. 48* `always` - Unconditionally allow the server to delegate. 49-- 50 51 52http.extraHeader:: 53 Pass an additional HTTP header when communicating with a server. If 54 more than one such entry exists, all of them are added as extra 55 headers. To allow overriding the settings inherited from the system 56 config, an empty value will reset the extra headers to the empty list. 57 58http.cookieFile:: 59 The pathname of a file containing previously stored cookie lines, 60 which should be used 61 in the Git http session, if they match the server. The file format 62 of the file to read cookies from should be plain HTTP headers or 63 the Netscape/Mozilla cookie file format (see `curl(1)`). 64 NOTE that the file specified with http.cookieFile is used only as 65 input unless http.saveCookies is set. 66 67http.saveCookies:: 68 If set, store cookies received during requests to the file specified by 69 http.cookieFile. Has no effect if http.cookieFile is unset. 70 71http.sslVersion:: 72 The SSL version to use when negotiating an SSL connection, if you 73 want to force the default. The available and default version 74 depend on whether libcurl was built against NSS or OpenSSL and the 75 particular configuration of the crypto library in use. Internally 76 this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl 77 documentation for more details on the format of this option and 78 for the ssl version supported. Actually the possible values of 79 this option are: 80 81 - sslv2 82 - sslv3 83 - tlsv1 84 - tlsv1.0 85 - tlsv1.1 86 - tlsv1.2 87 - tlsv1.3 88 89+ 90Can be overridden by the `GIT_SSL_VERSION` environment variable. 91To force git to use libcurl's default ssl version and ignore any 92explicit http.sslversion option, set `GIT_SSL_VERSION` to the 93empty string. 94 95http.sslCipherList:: 96 A list of SSL ciphers to use when negotiating an SSL connection. 97 The available ciphers depend on whether libcurl was built against 98 NSS or OpenSSL and the particular configuration of the crypto 99 library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST' 100 option; see the libcurl documentation for more details on the format 101 of this list. 102+ 103Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable. 104To force git to use libcurl's default cipher list and ignore any 105explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the 106empty string. 107 108http.sslVerify:: 109 Whether to verify the SSL certificate when fetching or pushing 110 over HTTPS. Defaults to true. Can be overridden by the 111 `GIT_SSL_NO_VERIFY` environment variable. 112 113http.sslCert:: 114 File containing the SSL certificate when fetching or pushing 115 over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment 116 variable. 117 118http.sslKey:: 119 File containing the SSL private key when fetching or pushing 120 over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment 121 variable. 122 123http.sslCertPasswordProtected:: 124 Enable Git's password prompt for the SSL certificate. Otherwise 125 OpenSSL will prompt the user, possibly many times, if the 126 certificate or private key is encrypted. Can be overridden by the 127 `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable. 128 129http.sslCAInfo:: 130 File containing the certificates to verify the peer with when 131 fetching or pushing over HTTPS. Can be overridden by the 132 `GIT_SSL_CAINFO` environment variable. 133 134http.sslCAPath:: 135 Path containing files with the CA certificates to verify the peer 136 with when fetching or pushing over HTTPS. Can be overridden 137 by the `GIT_SSL_CAPATH` environment variable. 138 139http.sslBackend:: 140 Name of the SSL backend to use (e.g. "openssl" or "schannel"). 141 This option is ignored if cURL lacks support for choosing the SSL 142 backend at runtime. 143 144http.schannelCheckRevoke:: 145 Used to enforce or disable certificate revocation checks in cURL 146 when http.sslBackend is set to "schannel". Defaults to `true` if 147 unset. Only necessary to disable this if Git consistently errors 148 and the message is about checking the revocation status of a 149 certificate. This option is ignored if cURL lacks support for 150 setting the relevant SSL option at runtime. 151 152http.schannelUseSSLCAInfo:: 153 As of cURL v7.60.0, the Secure Channel backend can use the 154 certificate bundle provided via `http.sslCAInfo`, but that would 155 override the Windows Certificate Store. Since this is not desirable 156 by default, Git will tell cURL not to use that bundle by default 157 when the `schannel` backend was configured via `http.sslBackend`, 158 unless `http.schannelUseSSLCAInfo` overrides this behavior. 159 160http.pinnedpubkey:: 161 Public key of the https service. It may either be the filename of 162 a PEM or DER encoded public key file or a string starting with 163 'sha256//' followed by the base64 encoded sha256 hash of the 164 public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will 165 exit with an error if this option is set but not supported by 166 cURL. 167 168http.sslTry:: 169 Attempt to use AUTH SSL/TLS and encrypted data transfers 170 when connecting via regular FTP protocol. This might be needed 171 if the FTP server requires it for security reasons or you wish 172 to connect securely whenever remote FTP server supports it. 173 Default is false since it might trigger certificate verification 174 errors on misconfigured servers. 175 176http.maxRequests:: 177 How many HTTP requests to launch in parallel. Can be overridden 178 by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5. 179 180http.minSessions:: 181 The number of curl sessions (counted across slots) to be kept across 182 requests. They will not be ended with curl_easy_cleanup() until 183 http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this 184 value will be capped at 1. Defaults to 1. 185 186http.postBuffer:: 187 Maximum size in bytes of the buffer used by smart HTTP 188 transports when POSTing data to the remote system. 189 For requests larger than this buffer size, HTTP/1.1 and 190 Transfer-Encoding: chunked is used to avoid creating a 191 massive pack file locally. Default is 1 MiB, which is 192 sufficient for most requests. 193 194http.lowSpeedLimit, http.lowSpeedTime:: 195 If the HTTP transfer speed is less than 'http.lowSpeedLimit' 196 for longer than 'http.lowSpeedTime' seconds, the transfer is aborted. 197 Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and 198 `GIT_HTTP_LOW_SPEED_TIME` environment variables. 199 200http.noEPSV:: 201 A boolean which disables using of EPSV ftp command by curl. 202 This can helpful with some "poor" ftp servers which don't 203 support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV` 204 environment variable. Default is false (curl will use EPSV). 205 206http.userAgent:: 207 The HTTP USER_AGENT string presented to an HTTP server. The default 208 value represents the version of the client Git such as git/1.7.1. 209 This option allows you to override this value to a more common value 210 such as Mozilla/4.0. This may be necessary, for instance, if 211 connecting through a firewall that restricts HTTP connections to a set 212 of common USER_AGENT strings (but not including those like git/1.7.1). 213 Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable. 214 215http.followRedirects:: 216 Whether git should follow HTTP redirects. If set to `true`, git 217 will transparently follow any redirect issued by a server it 218 encounters. If set to `false`, git will treat all redirects as 219 errors. If set to `initial`, git will follow redirects only for 220 the initial request to a remote, but not for subsequent 221 follow-up HTTP requests. Since git uses the redirected URL as 222 the base for the follow-up requests, this is generally 223 sufficient. The default is `initial`. 224 225http.<url>.*:: 226 Any of the http.* options above can be applied selectively to some URLs. 227 For a config key to match a URL, each element of the config key is 228 compared to that of the URL, in the following order: 229+ 230-- 231. Scheme (e.g., `https` in `https://example.com/`). This field 232 must match exactly between the config key and the URL. 233 234. Host/domain name (e.g., `example.com` in `https://example.com/`). 235 This field must match between the config key and the URL. It is 236 possible to specify a `*` as part of the host name to match all subdomains 237 at this level. `https://*.example.com/` for example would match 238 `https://foo.example.com/`, but not `https://foo.bar.example.com/`. 239 240. Port number (e.g., `8080` in `http://example.com:8080/`). 241 This field must match exactly between the config key and the URL. 242 Omitted port numbers are automatically converted to the correct 243 default for the scheme before matching. 244 245. Path (e.g., `repo.git` in `https://example.com/repo.git`). The 246 path field of the config key must match the path field of the URL 247 either exactly or as a prefix of slash-delimited path elements. This means 248 a config key with path `foo/` matches URL path `foo/bar`. A prefix can only 249 match on a slash (`/`) boundary. Longer matches take precedence (so a config 250 key with path `foo/bar` is a better match to URL path `foo/bar` than a config 251 key with just path `foo/`). 252 253. User name (e.g., `user` in `https://user@example.com/repo.git`). If 254 the config key has a user name it must match the user name in the 255 URL exactly. If the config key does not have a user name, that 256 config key will match a URL with any user name (including none), 257 but at a lower precedence than a config key with a user name. 258-- 259+ 260The list above is ordered by decreasing precedence; a URL that matches 261a config key's path is preferred to one that matches its user name. For example, 262if the URL is `https://user@example.com/foo/bar` a config key match of 263`https://example.com/foo` will be preferred over a config key match of 264`https://user@example.com`. 265+ 266All URLs are normalized before attempting any matching (the password part, 267if embedded in the URL, is always ignored for matching purposes) so that 268equivalent URLs that are simply spelled differently will match properly. 269Environment variable settings always override any matches. The URLs that are 270matched against are those given directly to Git commands. This means any URLs 271visited as a result of a redirection do not participate in matching.