be overridden by the `GIT_CURL_FTP_NO_EPSV`
	environment variable. Default is false (curl will use EPSV).

http.userAgent::
	The HTTP USER_AGENT string presented to an HTTP server.  The default
	value represents the version of the Git client such as git/1.7.1.
	This option allows you to override this value to a more common value
	such as Mozilla/4.0.  This may be necessary, for instance, if
	connecting through a firewall that restricts HTTP connections to a set
	of common USER_AGENT strings (but not including those like git/1.7.1).
	Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.

http.followRedirects::
	Whether git should follow HTTP redirects. If set to `true`, git
	will transparently follow any redirect issued by a server it
	encounters. If set to `false`, git will treat all redirects as
	errors. If set to `initial`, git will follow redirects only for
	the initial request to a remote, but not for subsequent
	follow-up HTTP requests. Since git uses the redirected URL as
	the base for the follow-up requests, this is generally
	sufficient. The default is `initial`.

http.<url>.*::
	Any of the http.* options above can be applied selectively to some URLs.
	For a config key to match a URL, each element of the config key is
	compared to that of the URL, in the following order:
+
--
. Scheme (e.g., `https` in `https://example.com/`). This field
  must match exactly between the config key and the URL.

. Host/domain name (e.g., `example.com` in `https://example.com/`).
  This field must match between the config key and the URL. It is
  possible to specify a `*` as part of the host name to match all subdomains
  at this level. `https://*.example.com/` for example would match
  `https://foo.example.com/`, but not `https://foo.bar.example.com/`.

. Port number (e.g., `8080` in `http://example.com:8080/`).
  This field must match exactly between the config key and the URL.
  Omitted port numbers are automatically converted to the correct
  default for the scheme before matching.

. Path (e.g., `repo.git` in `https://example.com/repo.git`). The
  path field of the config key must match the path field of the URL
  either exactly or as a prefix of slash-delimited path elements.  This means
  a config key with path `foo/` matches URL path `foo/bar`.  A prefix can only
  match on a slash (`/`) boundary.  Longer matches take precedence (so a config
  key with path `foo/bar` is a better match to URL path `foo/bar` than a config
  key with just path `foo/`).

. User name (e.g., `user` in `https://user@example.com/repo.git`). If
  the config key has a user name it must match the user name in the
  URL exactly. If the config key does not have a user name, that
  config key will match a URL with any user name (including none),
  but at a lower precedence than a config key with a user name.
--
+
The list above is ordered by decreasing precedence; a URL that matches
a config key's path is preferred to one that matches its user name. For example,
if the URL is `https://user@example.com/foo/bar` a config key match of
`https://example.com/foo` will be preferred over a config key match of
`https://user@example.com`.
+
All URLs are normalized before attempting any matching (the password part,
if embedded in the URL, is always ignored for matching purposes) so that
equivalent URLs that are simply spelled differently will match properly.
Environment variable settings always override any matches.  The URLs that are
matched against are those given directly to Git commands.  This means any URLs
visited as a result of a redirection do not participate in matching.