------------------
The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
-is used to store the configuration for that repository, and
+the Git commands' behavior. The files `.git/config` and optionally
+`config.worktree` (see `extensions.worktreeConfig` below) in each
+repository are used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
include::config/help.txt[]
-http.proxy::
- Override the HTTP proxy, normally configured using the 'http_proxy',
- 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
- addition to the syntax understood by curl, it is possible to specify a
- proxy string with a user name but no password, in which case git will
- attempt to acquire one in the same way it does for other credentials. See
- linkgit:gitcredentials[7] for more information. The syntax thus is
- '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
- on a per-remote basis; see remote.<name>.proxy
-
-http.proxyAuthMethod::
- Set the method with which to authenticate against the HTTP proxy. This
- only takes effect if the configured proxy string contains a user name part
- (i.e. is of the form 'user@host' or 'user@host:port'). This can be
- overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
- Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
- variable. Possible values are:
-+
---
-* `anyauth` - Automatically pick a suitable authentication method. It is
- assumed that the proxy answers an unauthenticated request with a 407
- status code and one or more Proxy-authenticate headers with supported
- authentication methods. This is the default.
-* `basic` - HTTP Basic authentication
-* `digest` - HTTP Digest authentication; this prevents the password from being
- transmitted to the proxy in clear text
-* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
- of `curl(1)`)
-* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
---
-
-http.emptyAuth::
- Attempt authentication without seeking a username or password. This
- can be used to attempt GSS-Negotiate authentication without specifying
- a username in the URL, as libcurl normally requires a username for
- authentication.
-
-http.delegation::
- Control GSSAPI credential delegation. The delegation is disabled
- by default in libcurl since version 7.21.7. Set parameter to tell
- the server what it is allowed to delegate when it comes to user
- credentials. Used with GSS/kerberos. Possible values are:
-+
---
-* `none` - Don't allow any delegation.
-* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
- Kerberos service ticket, which is a matter of realm policy.
-* `always` - Unconditionally allow the server to delegate.
---
-
-
-http.extraHeader::
- Pass an additional HTTP header when communicating with a server. If
- more than one such entry exists, all of them are added as extra
- headers. To allow overriding the settings inherited from the system
- config, an empty value will reset the extra headers to the empty list.
-
-http.cookieFile::
- The pathname of a file containing previously stored cookie lines,
- which should be used
- in the Git http session, if they match the server. The file format
- of the file to read cookies from should be plain HTTP headers or
- the Netscape/Mozilla cookie file format (see `curl(1)`).
- NOTE that the file specified with http.cookieFile is used only as
- input unless http.saveCookies is set.
-
-http.saveCookies::
- If set, store cookies received during requests to the file specified by
- http.cookieFile. Has no effect if http.cookieFile is unset.
-
-http.sslVersion::
- The SSL version to use when negotiating an SSL connection, if you
- want to force the default. The available and default version
- depend on whether libcurl was built against NSS or OpenSSL and the
- particular configuration of the crypto library in use. Internally
- this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
- documentation for more details on the format of this option and
- for the ssl version supported. Actually the possible values of
- this option are:
-
- - sslv2
- - sslv3
- - tlsv1
- - tlsv1.0
- - tlsv1.1
- - tlsv1.2
- - tlsv1.3
+include::config/http.txt[]
-+
-Can be overridden by the `GIT_SSL_VERSION` environment variable.
-To force git to use libcurl's default ssl version and ignore any
-explicit http.sslversion option, set `GIT_SSL_VERSION` to the
-empty string.
-
-http.sslCipherList::
- A list of SSL ciphers to use when negotiating an SSL connection.
- The available ciphers depend on whether libcurl was built against
- NSS or OpenSSL and the particular configuration of the crypto
- library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
- option; see the libcurl documentation for more details on the format
- of this list.
-+
-Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
-To force git to use libcurl's default cipher list and ignore any
-explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
-empty string.
-
-http.sslVerify::
- Whether to verify the SSL certificate when fetching or pushing
- over HTTPS. Defaults to true. Can be overridden by the
- `GIT_SSL_NO_VERIFY` environment variable.
-
-http.sslCert::
- File containing the SSL certificate when fetching or pushing
- over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
- variable.
-
-http.sslKey::
- File containing the SSL private key when fetching or pushing
- over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
- variable.
-
-http.sslCertPasswordProtected::
- Enable Git's password prompt for the SSL certificate. Otherwise
- OpenSSL will prompt the user, possibly many times, if the
- certificate or private key is encrypted. Can be overridden by the
- `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
-
-http.sslCAInfo::
- File containing the certificates to verify the peer with when
- fetching or pushing over HTTPS. Can be overridden by the
- `GIT_SSL_CAINFO` environment variable.
-
-http.sslCAPath::
- Path containing files with the CA certificates to verify the peer
- with when fetching or pushing over HTTPS. Can be overridden
- by the `GIT_SSL_CAPATH` environment variable.
-
-http.sslBackend::
- Name of the SSL backend to use (e.g. "openssl" or "schannel").
- This option is ignored if cURL lacks support for choosing the SSL
- backend at runtime.
-
-http.schannelCheckRevoke::
- Used to enforce or disable certificate revocation checks in cURL
- when http.sslBackend is set to "schannel". Defaults to `true` if
- unset. Only necessary to disable this if Git consistently errors
- and the message is about checking the revocation status of a
- certificate. This option is ignored if cURL lacks support for
- setting the relevant SSL option at runtime.
-
-http.schannelUseSSLCAInfo::
- As of cURL v7.60.0, the Secure Channel backend can use the
- certificate bundle provided via `http.sslCAInfo`, but that would
- override the Windows Certificate Store. Since this is not desirable
- by default, Git will tell cURL not to use that bundle by default
- when the `schannel` backend was configured via `http.sslBackend`,
- unless `http.schannelUseSSLCAInfo` overrides this behavior.
-
-http.pinnedpubkey::
- Public key of the https service. It may either be the filename of
- a PEM or DER encoded public key file or a string starting with
- 'sha256//' followed by the base64 encoded sha256 hash of the
- public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
- exit with an error if this option is set but not supported by
- cURL.
-
-http.sslTry::
- Attempt to use AUTH SSL/TLS and encrypted data transfers
- when connecting via regular FTP protocol. This might be needed
- if the FTP server requires it for security reasons or you wish
- to connect securely whenever remote FTP server supports it.
- Default is false since it might trigger certificate verification
- errors on misconfigured servers.
-
-http.maxRequests::
- How many HTTP requests to launch in parallel. Can be overridden
- by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
-
-http.minSessions::
- The number of curl sessions (counted across slots) to be kept across
- requests. They will not be ended with curl_easy_cleanup() until
- http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
- value will be capped at 1. Defaults to 1.
-
-http.postBuffer::
- Maximum size in bytes of the buffer used by smart HTTP
- transports when POSTing data to the remote system.
- For requests larger than this buffer size, HTTP/1.1 and
- Transfer-Encoding: chunked is used to avoid creating a
- massive pack file locally. Default is 1 MiB, which is
- sufficient for most requests.
-
-http.lowSpeedLimit, http.lowSpeedTime::
- If the HTTP transfer speed is less than 'http.lowSpeedLimit'
- for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
- Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
- `GIT_HTTP_LOW_SPEED_TIME` environment variables.
-
-http.noEPSV::
- A boolean which disables using of EPSV ftp command by curl.
- This can helpful with some "poor" ftp servers which don't
- support EPSV mode. Can 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 client Git 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.
-
-ssh.variant::
- By default, Git determines the command line arguments to use
- based on the basename of the configured SSH command (configured
- using the environment variable `GIT_SSH` or `GIT_SSH_COMMAND` or
- the config setting `core.sshCommand`). If the basename is
- unrecognized, Git will attempt to detect support of OpenSSH
- options by first invoking the configured SSH command with the
- `-G` (print configuration) option and will subsequently use
- OpenSSH options (if that is successful) or no options besides
- the host and remote command (if it fails).
-+
-The config variable `ssh.variant` can be set to override this detection.
-Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
-`tortoiseplink`, `simple` (no options except the host and remote command).
-The default auto-detection can be explicitly requested using the value
-`auto`. Any other value is treated as `ssh`. This setting can also be
-overridden via the environment variable `GIT_SSH_VARIANT`.
-+
-The current command-line parameters used for each variant are as
-follows:
-+
---
+include::config/i18n.txt[]
-* `ssh` - [-p port] [-4] [-6] [-o option] [username@]host command
+include::config/imap.txt[]
-* `simple` - [username@]host command
+include::config/index.txt[]
-* `plink` or `putty` - [-P port] [-4] [-6] [username@]host command
+include::config/init.txt[]
-* `tortoiseplink` - [-P port] [-4] [-6] -batch [username@]host command
+include::config/instaweb.txt[]
---
-+
-Except for the `simple` variant, command-line parameters are likely to
-change as git gains new features.
-
-i18n.commitEncoding::
- Character encoding the commit messages are stored in; Git itself
- does not care per se, but this information is necessary e.g. when
- importing commits from emails or in the gitk graphical history
- browser (and possibly at other places in the future or in other
- porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
-
-i18n.logOutputEncoding::
- Character encoding the commit messages are converted to when
- running 'git log' and friends.
-
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-index.threads::
- Specifies the number of threads to spawn when loading the index.
- This is meant to reduce index load time on multiprocessor machines.
- Specifying 0 or 'true' will cause Git to auto-detect the number of
- CPU's and set the number of threads accordingly. Specifying 1 or
- 'false' will disable multithreading. Defaults to 'true'.
-
-index.version::
- Specify the version with which new index files should be
- initialized. This does not affect existing repositories.
-
-init.templateDir::
- Specify the directory from which templates will be copied.
- (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
-
-instaweb.browser::
- Specify the program that will be used to browse your working
- repository in gitweb. See linkgit:git-instaweb[1].
-
-instaweb.httpd::
- The HTTP daemon command-line to start gitweb on your working
- repository. See linkgit:git-instaweb[1].
-
-instaweb.local::
- If true the web server started by linkgit:git-instaweb[1] will
- be bound to the local IP (127.0.0.1).
-
-instaweb.modulePath::
- The default module path for linkgit:git-instaweb[1] to use
- instead of /usr/lib/apache2/modules. Only used if httpd
- is Apache.
-
-instaweb.port::
- The port number to bind the gitweb httpd to. See
- linkgit:git-instaweb[1].
-
-interactive.singleKey::
- In interactive commands, allow the user to provide one-letter
- input with a single key (i.e., without hitting enter).
- Currently this is used by the `--patch` mode of
- linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
- linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
- setting is silently ignored if portable keystroke input
- is not available; requires the Perl module Term::ReadKey.
-
-interactive.diffFilter::
- When an interactive command (such as `git add --patch`) shows
- a colorized diff, git will pipe the diff through the shell
- command defined by this configuration variable. The command may
- mark up the diff further for human consumption, provided that it
- retains a one-to-one correspondence with the lines in the
- original diff. Defaults to disabled (no filtering).
-
-log.abbrevCommit::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
- override this option with `--no-abbrev-commit`.
-
-log.date::
- Set the default date-time mode for the 'log' command.
- Setting a value for log.date is similar to using 'git log''s
- `--date` option. See linkgit:git-log[1] for details.
-
-log.decorate::
- Print out the ref names of any commits that are shown by the log
- command. If 'short' is specified, the ref name prefixes 'refs/heads/',
- 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
- specified, the full ref name (including prefix) will be printed.
- If 'auto' is specified, then if the output is going to a terminal,
- the ref names are shown as if 'short' were given, otherwise no ref
- names are shown. This is the same as the `--decorate` option
- of the `git log`.
-
-log.follow::
- If `true`, `git log` will act as if the `--follow` option was used when
- a single <path> is given. This has the same limitations as `--follow`,
- i.e. it cannot be used to follow multiple files and does not work well
- on non-linear history.
-
-log.graphColors::
- A list of colors, separated by commas, that can be used to draw
- history lines in `git log --graph`.
-
-log.showRoot::
- If true, the initial commit will be shown as a big creation event.
- This is equivalent to a diff against an empty tree.
- Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
- normally hide the root commit will now show it. True by default.
-
-log.showSignature::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--show-signature`.
-
-log.mailmap::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--use-mailmap`.
-
-mailinfo.scissors::
- If true, makes linkgit:git-mailinfo[1] (and therefore
- linkgit:git-am[1]) act by default as if the --scissors option
- was provided on the command-line. When active, this features
- removes everything from the message body before a scissors
- line (i.e. consisting mainly of ">8", "8<" and "-").
-
-mailmap.file::
- The location of an augmenting mailmap file. The default
- mailmap, located in the root of the repository, is loaded
- first, then the mailmap file pointed to by this variable.
- The location of the mailmap file may be in a repository
- subdirectory, or somewhere outside of the repository itself.
- See linkgit:git-shortlog[1] and linkgit:git-blame[1].
-
-mailmap.blob::
- Like `mailmap.file`, but consider the value as a reference to a
- blob in the repository. If both `mailmap.file` and
- `mailmap.blob` are given, both are parsed, with entries from
- `mailmap.file` taking precedence. In a bare repository, this
- defaults to `HEAD:.mailmap`. In a non-bare repository, it
- defaults to empty.
-
-man.viewer::
- Specify the programs that may be used to display help in the
- 'man' format. See linkgit:git-help[1].
-
-man.<tool>.cmd::
- Specify the command to invoke the specified man viewer. The
- specified command is evaluated in shell with the man page
- passed as argument. (See linkgit:git-help[1].)
-
-man.<tool>.path::
- Override the path for the given tool that may be used to
- display help in the 'man' format. See linkgit:git-help[1].
-
-include::merge-config.txt[]
-
-mergetool.<tool>.path::
- Override the path for the given tool. This is useful in case
- your tool is not in the PATH.
-
-mergetool.<tool>.cmd::
- Specify the command to invoke the specified merge tool. The
- specified command is evaluated in shell with the following
- variables available: 'BASE' is the name of a temporary file
- containing the common base of the files to be merged, if available;
- 'LOCAL' is the name of a temporary file containing the contents of
- the file on the current branch; 'REMOTE' is the name of a temporary
- file containing the contents of the file from the branch being
- merged; 'MERGED' contains the name of the file to which the merge
- tool should write the results of a successful merge.
-
-mergetool.<tool>.trustExitCode::
- For a custom merge command, specify whether the exit code of
- the merge command can be used to determine whether the merge was
- successful. If this is not set to true then the merge target file
- timestamp is checked and the merge assumed to have been successful
- if the file has been updated, otherwise the user is prompted to
- indicate the success of the merge.
-
-mergetool.meld.hasOutput::
- Older versions of `meld` do not support the `--output` option.
- Git will attempt to detect whether `meld` supports `--output`
- by inspecting the output of `meld --help`. Configuring
- `mergetool.meld.hasOutput` will make Git skip these checks and
- use the configured value instead. Setting `mergetool.meld.hasOutput`
- to `true` tells Git to unconditionally use the `--output` option,
- and `false` avoids using `--output`.
-
-mergetool.keepBackup::
- After performing a merge, the original file with conflict markers
- can be saved as a file with a `.orig` extension. If this variable
- is set to `false` then this file is not preserved. Defaults to
- `true` (i.e. keep the backup files).
-
-mergetool.keepTemporaries::
- When invoking a custom merge tool, Git uses a set of temporary
- files to pass to the tool. If the tool returns an error and this
- variable is set to `true`, then these temporary files will be
- preserved, otherwise they will be removed after the tool has
- exited. Defaults to `false`.
-
-mergetool.writeToTemp::
- Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
- conflicting files in the worktree by default. Git will attempt
- to use a temporary directory for these files when set `true`.
- Defaults to `false`.
-
-mergetool.prompt::
- Prompt before each invocation of the merge resolution program.
-
-notes.mergeStrategy::
- Which merge strategy to choose by default when resolving notes
- conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
- `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
- section of linkgit:git-notes[1] for more information on each strategy.
-
-notes.<name>.mergeStrategy::
- Which merge strategy to choose when doing a notes merge into
- refs/notes/<name>. This overrides the more general
- "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
- linkgit:git-notes[1] for more information on the available strategies.
-
-notes.displayRef::
- The (fully qualified) refname from which to show notes when
- showing commit messages. The value of this variable can be set
- to a glob, in which case notes from all matching refs will be
- shown. You may also specify this configuration variable
- several times. A warning will be issued for refs that do not
- exist, but a glob that does not match any refs is silently
- ignored.
-+
-This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-+
-The effective value of "core.notesRef" (possibly overridden by
-GIT_NOTES_REF) is also implicitly added to the list of refs to be
-displayed.
-
-notes.rewrite.<command>::
- When rewriting commits with <command> (currently `amend` or
- `rebase`) and this variable is set to `true`, Git
- automatically copies your notes from the original to the
- rewritten commit. Defaults to `true`, but see
- "notes.rewriteRef" below.
-
-notes.rewriteMode::
- When copying notes during a rewrite (see the
- "notes.rewrite.<command>" option), determines what to do if
- the target commit already has a note. Must be one of
- `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
- Defaults to `concatenate`.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
-environment variable.
-
-notes.rewriteRef::
- When copying notes during a rewrite, specifies the (fully
- qualified) ref whose notes should be copied. The ref may be a
- glob, in which case notes in all matching refs will be copied.
- You may also specify this configuration several times.
-+
-Does not have a default value; you must configure this variable to
-enable note rewriting. Set it to `refs/notes/commits` to enable
-rewriting for the default commit notes.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-
-pack.window::
- The size of the window used by linkgit:git-pack-objects[1] when no
- window size is given on the command line. Defaults to 10.
-
-pack.depth::
- The maximum delta depth used by linkgit:git-pack-objects[1] when no
- maximum depth is given on the command line. Defaults to 50.
- Maximum value is 4095.
-
-pack.windowMemory::
- The maximum size of memory that is consumed by each thread
- in linkgit:git-pack-objects[1] for pack window memory when
- no limit is given on the command line. The value can be
- suffixed with "k", "m", or "g". When left unconfigured (or
- set explicitly to 0), there will be no limit.
-
-pack.compression::
- An integer -1..9, indicating the compression level for objects
- in a pack file. -1 is the zlib default. 0 means no
- compression, and 1..9 are various speed/size tradeoffs, 9 being
- slowest. If not set, defaults to core.compression. If that is
- not set, defaults to -1, the zlib default, which is "a default
- compromise between speed and compression (currently equivalent
- to level 6)."
-+
-Note that changing the compression level will not automatically recompress
-all existing objects. You can force recompression by passing the -F option
-to linkgit:git-repack[1].
-
-pack.island::
- An extended regular expression configuring a set of delta
- islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
- for details.
-
-pack.islandCore::
- Specify an island name which gets to have its objects be
- packed first. This creates a kind of pseudo-pack at the front
- of one pack, so that the objects from the specified island are
- hopefully faster to copy into any pack that should be served
- to a user requesting these objects. In practice this means
- that the island specified should likely correspond to what is
- the most commonly cloned in the repo. See also "DELTA ISLANDS"
- in linkgit:git-pack-objects[1].
-
-pack.deltaCacheSize::
- The maximum memory in bytes used for caching deltas in
- linkgit:git-pack-objects[1] before writing them out to a pack.
- This cache is used to speed up the writing object phase by not
- having to recompute the final delta result once the best match
- for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
- especially if this cache pushes the system into swapping.
- A value of 0 means no limit. The smallest size of 1 byte may be
- used to virtually disable this cache. Defaults to 256 MiB.
-
-pack.deltaCacheLimit::
- The maximum size of a delta, that is cached in
- linkgit:git-pack-objects[1]. This cache is used to speed up the
- writing object phase by not having to recompute the final delta
- result once the best match for all objects is found.
- Defaults to 1000. Maximum value is 65535.
-
-pack.threads::
- Specifies the number of threads to spawn when searching for best
- delta matches. This requires that linkgit:git-pack-objects[1]
- be compiled with pthreads otherwise this option is ignored with a
- warning. This is meant to reduce packing time on multiprocessor
- machines. The required amount of memory for the delta search window
- is however multiplied by the number of threads.
- Specifying 0 will cause Git to auto-detect the number of CPU's
- and set the number of threads accordingly.
-
-pack.indexVersion::
- Specify the default pack index version. Valid values are 1 for
- legacy pack index used by Git versions prior to 1.5.2, and 2 for
- the new pack index with capabilities for packs larger than 4 GB
- as well as proper protection against the repacking of corrupted
- packs. Version 2 is the default. Note that version 2 is enforced
- and this config option ignored whenever the corresponding pack is
- larger than 2 GB.
-+
-If you have an old Git that does not understand the version 2 `*.idx` file,
-cloning or fetching over a non native protocol (e.g. "http")
-that will copy both `*.pack` file and corresponding `*.idx` file from the
-other side may give you a repository that cannot be accessed with your
-older version of Git. If the `*.pack` file is smaller than 2 GB, however,
-you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
-the `*.idx` file.
-
-pack.packSizeLimit::
- The maximum size of a pack. This setting only affects
- packing to a file when repacking, i.e. the git:// protocol
- is unaffected. It can be overridden by the `--max-pack-size`
- option of linkgit:git-repack[1]. Reaching this limit results
- in the creation of multiple packfiles; which in turn prevents
- bitmaps from being created.
- The minimum size allowed is limited to 1 MiB.
- The default is unlimited.
- Common unit suffixes of 'k', 'm', or 'g' are
- supported.
-
-pack.useBitmaps::
- When true, git will use pack bitmaps (if available) when packing
- to stdout (e.g., during the server side of a fetch). Defaults to
- true. You should not generally need to turn this off unless
- you are debugging pack bitmaps.
-
-pack.writeBitmaps (deprecated)::
- This is a deprecated synonym for `repack.writeBitmaps`.
-
-pack.writeBitmapHashCache::
- When true, git will include a "hash cache" section in the bitmap
- index (if one is written). This cache can be used to feed git's
- delta heuristics, potentially leading to better deltas between
- bitmapped and non-bitmapped objects (e.g., when serving a fetch
- between an older, bitmapped pack and objects that have been
- pushed since the last gc). The downside is that it consumes 4
- bytes per object of disk space, and that JGit's bitmap
- implementation does not understand it, causing it to complain if
- Git and JGit are used on the same repository. Defaults to false.
-
-pager.<cmd>::
- If the value is boolean, turns on or off pagination of the
- output of a particular Git subcommand when writing to a tty.
- Otherwise, turns on pagination for the subcommand using the
- pager specified by the value of `pager.<cmd>`. If `--paginate`
- or `--no-pager` is specified on the command line, it takes
- precedence over this option. To disable pagination for all
- commands, set `core.pager` or `GIT_PAGER` to `cat`.
-
-pretty.<name>::
- Alias for a --pretty= format string, as specified in
- linkgit:git-log[1]. Any aliases defined here can be used just
- as the built-in pretty formats could. For example,
- running `git config pretty.changelog "format:* %H %s"`
- would cause the invocation `git log --pretty=changelog`
- to be equivalent to running `git log "--pretty=format:* %H %s"`.
- Note that an alias with the same name as a built-in format
- will be silently ignored.
-
-protocol.allow::
- If set, provide a user defined default policy for all protocols which
- don't explicitly have a policy (`protocol.<name>.allow`). By default,
- if unset, known-safe protocols (http, https, git, ssh, file) have a
- default policy of `always`, known-dangerous protocols (ext) have a
- default policy of `never`, and all other protocols have a default
- policy of `user`. Supported policies:
-+
---
+include::config/interactive.txt[]
-* `always` - protocol is always able to be used.
+include::config/log.txt[]
-* `never` - protocol is never able to be used.
+include::config/mailinfo.txt[]
-* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
- either unset or has a value of 1. This policy should be used when you want a
- protocol to be directly usable by the user but don't want it used by commands which
- execute clone/fetch/push commands without user input, e.g. recursive
- submodule initialization.
+include::config/mailmap.txt[]
---
+include::config/man.txt[]
-protocol.<name>.allow::
- Set a policy to be used by protocol `<name>` with clone/fetch/push
- commands. See `protocol.allow` above for the available policies.
-+
-The protocol names currently used by git are:
-+
---
- - `file`: any local file-based path (including `file://` URLs,
- or local paths)
-
- - `git`: the anonymous git protocol over a direct TCP
- connection (or proxy, if configured)
-
- - `ssh`: git over ssh (including `host:path` syntax,
- `ssh://`, etc).
-
- - `http`: git over http, both "smart http" and "dumb http".
- Note that this does _not_ include `https`; if you want to configure
- both, you must do so individually.
-
- - any external helpers are named by their protocol (e.g., use
- `hg` to allow the `git-remote-hg` helper)
---
-
-protocol.version::
- Experimental. If set, clients will attempt to communicate with a
- server using the specified protocol version. If unset, no
- attempt will be made by the client to communicate using a
- particular protocol version, this results in protocol version 0
- being used.
- Supported versions:
-+
---
+include::config/merge.txt[]
-* `0` - the original wire protocol.
+include::config/mergetool.txt[]
-* `1` - the original wire protocol with the addition of a version string
- in the initial response from the server.
+include::config/notes.txt[]
-* `2` - link:technical/protocol-v2.html[wire protocol version 2].
+include::config/pack.txt[]
---
+include::config/pager.txt[]
-include::pull-config.txt[]
+include::config/pretty.txt[]
-include::push-config.txt[]
+include::config/protocol.txt[]
-include::rebase-config.txt[]
+include::config/pull.txt[]
-include::receive-config.txt[]
+include::config/push.txt[]
-remote.pushDefault::
- The remote to push to by default. Overrides
- `branch.<name>.remote` for all branches, and is overridden by
- `branch.<name>.pushRemote` for specific branches.
+include::config/rebase.txt[]
-remote.<name>.url::
- The URL of a remote repository. See linkgit:git-fetch[1] or
- linkgit:git-push[1].
+include::config/receive.txt[]
-remote.<name>.pushurl::
- The push URL of a remote repository. See linkgit:git-push[1].
+include::config/remote.txt[]
-remote.<name>.proxy::
- For remotes that require curl (http, https and ftp), the URL to
- the proxy to use for that remote. Set to the empty string to
- disable proxying for that remote.
+include::config/remotes.txt[]
-remote.<name>.proxyAuthMethod::
- For remotes that require curl (http, https and ftp), the method to use for
- authenticating against the proxy in use (probably set in
- `remote.<name>.proxy`). See `http.proxyAuthMethod`.
+include::config/repack.txt[]
-remote.<name>.fetch::
- The default set of "refspec" for linkgit:git-fetch[1]. See
- linkgit:git-fetch[1].
+include::config/rerere.txt[]
-remote.<name>.push::
- The default set of "refspec" for linkgit:git-push[1]. See
- linkgit:git-push[1].
+include::config/reset.txt[]
-remote.<name>.mirror::
- If true, pushing to this remote will automatically behave
- as if the `--mirror` option was given on the command line.
+include::config/sendemail.txt[]
-remote.<name>.skipDefaultUpdate::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
+include::config/sequencer.txt[]
-remote.<name>.skipFetchAll::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
+include::config/showbranch.txt[]
-remote.<name>.receivepack::
- The default program to execute on the remote side when pushing. See
- option --receive-pack of linkgit:git-push[1].
+include::config/splitindex.txt[]
-remote.<name>.uploadpack::
- The default program to execute on the remote side when fetching. See
- option --upload-pack of linkgit:git-fetch-pack[1].
+include::config/ssh.txt[]
-remote.<name>.tagOpt::
- Setting this value to --no-tags disables automatic tag following when
- fetching from remote <name>. Setting it to --tags will fetch every
- tag from remote <name>, even if they are not reachable from remote
- branch heads. Passing these flags directly to linkgit:git-fetch[1] can
- override this setting. See options --tags and --no-tags of
- linkgit:git-fetch[1].
+include::config/status.txt[]
-remote.<name>.vcs::
- Setting this to a value <vcs> will cause Git to interact with
- the remote with the git-remote-<vcs> helper.
+include::config/stash.txt[]
-remote.<name>.prune::
- When set to true, fetching from this remote by default will also
- remove any remote-tracking references that no longer exist on the
- remote (as if the `--prune` option was given on the command line).
- Overrides `fetch.prune` settings, if any.
+include::config/submodule.txt[]
-remote.<name>.pruneTags::
- When set to true, fetching from this remote by default will also
- remove any local tags that no longer exist on the remote if pruning
- is activated in general via `remote.<name>.prune`, `fetch.prune` or
- `--prune`. Overrides `fetch.pruneTags` settings, if any.
-+
-See also `remote.<name>.prune` and the PRUNING section of
-linkgit:git-fetch[1].
-
-remotes.<group>::
- The list of remotes which are fetched by "git remote update
- <group>". See linkgit:git-remote[1].
-
-repack.useDeltaBaseOffset::
- By default, linkgit:git-repack[1] creates packs that use
- delta-base offset. If you need to share your repository with
- Git older than version 1.4.4, either directly or via a dumb
- protocol such as http, then you need to set this option to
- "false" and repack. Access from old Git versions over the
- native protocol are unaffected by this option.
-
-repack.packKeptObjects::
- If set to true, makes `git repack` act as if
- `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
- details. Defaults to `false` normally, but `true` if a bitmap
- index is being written (either via `--write-bitmap-index` or
- `repack.writeBitmaps`).
-
-repack.useDeltaIslands::
- If set to true, makes `git repack` act as if `--delta-islands`
- was passed. Defaults to `false`.
-
-repack.writeBitmaps::
- When true, git will write a bitmap index when packing all
- objects to disk (e.g., when `git repack -a` is run). This
- index can speed up the "counting objects" phase of subsequent
- packs created for clones and fetches, at the cost of some disk
- space and extra time spent on the initial repack. This has
- no effect if multiple packfiles are created.
- Defaults to false.
-
-rerere.autoUpdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they be
- encountered again. By default, linkgit:git-rerere[1] is
- enabled if there is an `rr-cache` directory under the
- `$GIT_DIR`, e.g. if "rerere" was previously used in the
- repository.
-
-reset.quiet::
- When set to true, 'git reset' will default to the '--quiet' option.
-
-include::sendemail-config.txt[]
-
-sequence.editor::
- Text editor used by `git rebase -i` for editing the rebase instruction file.
- The value is meant to be interpreted by the shell when it is used.
- It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
- When not configured the default commit message editor is used instead.
-
-showBranch.default::
- The default set of branches for linkgit:git-show-branch[1].
- See linkgit:git-show-branch[1].
-
-splitIndex.maxPercentChange::
- When the split index feature is used, this specifies the
- percent of entries the split index can contain compared to the
- total number of entries in both the split index and the shared
- index before a new shared index is written.
- The value should be between 0 and 100. If the value is 0 then
- a new shared index is always written, if it is 100 a new
- shared index is never written.
- By default the value is 20, so a new shared index is written
- if the number of entries in the split index would be greater
- than 20 percent of the total number of entries.
- See linkgit:git-update-index[1].
-
-splitIndex.sharedIndexExpire::
- When the split index feature is used, shared index files that
- were not modified since the time this variable specifies will
- be removed when a new shared index file is created. The value
- "now" expires all entries immediately, and "never" suppresses
- expiration altogether.
- The default value is "2.weeks.ago".
- Note that a shared index file is considered modified (for the
- purpose of expiration) each time a new split-index file is
- either created based on it or read from it.
- See linkgit:git-update-index[1].
-
-status.relativePaths::
- By default, linkgit:git-status[1] shows paths relative to the
- current directory. Setting this variable to `false` shows paths
- relative to the repository root (this was the default for Git
- prior to v1.5.4).
-
-status.short::
- Set to true to enable --short by default in linkgit:git-status[1].
- The option --no-short takes precedence over this variable.
-
-status.branch::
- Set to true to enable --branch by default in linkgit:git-status[1].
- The option --no-branch takes precedence over this variable.
-
-status.displayCommentPrefix::
- If set to true, linkgit:git-status[1] will insert a comment
- prefix before each output line (starting with
- `core.commentChar`, i.e. `#` by default). This was the
- behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
- Defaults to false.
-
-status.renameLimit::
- The number of files to consider when performing rename detection
- in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
- the value of diff.renameLimit.
-
-status.renames::
- Whether and how Git detects renames in linkgit:git-status[1] and
- linkgit:git-commit[1] . If set to "false", rename detection is
- disabled. If set to "true", basic rename detection is enabled.
- If set to "copies" or "copy", Git will detect copies, as well.
- Defaults to the value of diff.renames.
-
-status.showStash::
- If set to true, linkgit:git-status[1] will display the number of
- entries currently stashed away.
- Defaults to false.
-
-status.showUntrackedFiles::
- By default, linkgit:git-status[1] and linkgit:git-commit[1] show
- files which are not currently tracked by Git. Directories which
- contain only untracked files, are shown with the directory name
- only. Showing untracked files means that Git needs to lstat() all
- the files in the whole repository, which might be slow on some
- systems. So, this variable controls how the commands displays
- the untracked files. Possible values are:
-+
---
-* `no` - Show no untracked files.
-* `normal` - Show untracked files and directories.
-* `all` - Show also individual files in untracked directories.
---
-+
-If this variable is not specified, it defaults to 'normal'.
-This variable can be overridden with the -u|--untracked-files option
-of linkgit:git-status[1] and linkgit:git-commit[1].
-
-status.submoduleSummary::
- Defaults to false.
- If this is set to a non zero number or true (identical to -1 or an
- unlimited number), the submodule summary will be enabled and a
- summary of commits for modified submodules will be shown (see
- --summary-limit option of linkgit:git-submodule[1]). Please note
- that the summary output command will be suppressed for all
- submodules when `diff.ignoreSubmodules` is set to 'all' or only
- for those submodules where `submodule.<name>.ignore=all`. The only
- exception to that rule is that status and commit will show staged
- submodule changes. To
- also view the summary for ignored submodules you can either use
- the --ignore-submodules=dirty command-line option or the 'git
- submodule summary' command, which shows a similar output but does
- not honor these settings.
-
-stash.showPatch::
- If this is set to true, the `git stash show` command without an
- option will show the stash entry in patch form. Defaults to false.
- See description of 'show' command in linkgit:git-stash[1].
-
-stash.showStat::
- If this is set to true, the `git stash show` command without an
- option will show diffstat of the stash entry. Defaults to true.
- See description of 'show' command in linkgit:git-stash[1].
-
-include::submodule-config.txt[]
-
-tag.forceSignAnnotated::
- A boolean to specify whether annotated tags created should be GPG signed.
- If `--annotate` is specified on the command line, it takes
- precedence over this option.
-
-tag.sort::
- This variable controls the sort ordering of tags when displayed by
- linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
- value of this variable will be used as the default.
-
-tar.umask::
- This variable can be used to restrict the permission bits of
- tar archive entries. The default is 0002, which turns off the
- world write bit. The special value "user" indicates that the
- archiving user's umask will be used instead. See umask(2) and
- linkgit:git-archive[1].
-
-transfer.fsckObjects::
- When `fetch.fsckObjects` or `receive.fsckObjects` are
- not set, the value of this variable is used instead.
- Defaults to false.
-+
-When set, the fetch or receive will abort in the case of a malformed
-object or a link to a nonexistent object. In addition, various other
-issues are checked for, including legacy issues (see `fsck.<msg-id>`),
-and potential security issues like the existence of a `.GIT` directory
-or a malicious `.gitmodules` file (see the release notes for v2.2.1
-and v2.17.1 for details). Other sanity and security checks may be
-added in future releases.
-+
-On the receiving side, failing fsckObjects will make those objects
-unreachable, see "QUARANTINE ENVIRONMENT" in
-linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
-instead be left unreferenced in the repository.
-+
-Due to the non-quarantine nature of the `fetch.fsckObjects`
-implementation it can not be relied upon to leave the object store
-clean like `receive.fsckObjects` can.
-+
-As objects are unpacked they're written to the object store, so there
-can be cases where malicious objects get introduced even though the
-"fetch" failed, only to have a subsequent "fetch" succeed because only
-new incoming objects are checked, not those that have already been
-written to the object store. That difference in behavior should not be
-relied upon. In the future, such objects may be quarantined for
-"fetch" as well.
-+
-For now, the paranoid need to find some way to emulate the quarantine
-environment if they'd like the same protection as "push". E.g. in the
-case of an internal mirror do the mirroring in two steps, one to fetch
-the untrusted objects, and then do a second "push" (which will use the
-quarantine) to another internal repo, and have internal clients
-consume this pushed-to repository, or embargo internal fetches and
-only allow them once a full "fsck" has run (and no new fetches have
-happened in the meantime).
-
-transfer.hideRefs::
- String(s) `receive-pack` and `upload-pack` use to decide which
- refs to omit from their initial advertisements. Use more than
- one definition to specify multiple prefix strings. A ref that is
- under the hierarchies listed in the value of this variable is
- excluded, and is hidden when responding to `git push` or `git
- fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
- program-specific versions of this config.
-+
-You may also include a `!` in front of the ref name to negate the entry,
-explicitly exposing it, even if an earlier entry marked it as hidden.
-If you have multiple hideRefs values, later entries override earlier ones
-(and entries in more-specific config files override less-specific ones).
-+
-If a namespace is in use, the namespace prefix is stripped from each
-reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
-"have" lines. In order to match refs before stripping, add a `^` in front of
-the ref name. If you combine `!` and `^`, `!` must be specified first.
-+
-Even if you hide refs, a client may still be able to steal the target
-objects via the techniques described in the "SECURITY" section of the
-linkgit:gitnamespaces[7] man page; it's best to keep private data in a
-separate repository.
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
-uploadarchive.allowUnreachable::
- If true, allow clients to use `git archive --remote` to request
- any tree, whether reachable from the ref tips or not. See the
- discussion in the "SECURITY" section of
- linkgit:git-upload-archive[1] for more details. Defaults to
- `false`.
-
-uploadpack.hideRefs::
- This variable is the same as `transfer.hideRefs`, but applies
- only to `upload-pack` (and so affects only fetches, not pushes).
- An attempt to fetch a hidden ref by `git fetch` will fail. See
- also `uploadpack.allowTipSHA1InWant`.
-
-uploadpack.allowTipSHA1InWant::
- When `uploadpack.hideRefs` is in effect, allow `upload-pack`
- to accept a fetch request that asks for an object at the tip
- of a hidden ref (by default, such a request is rejected).
- See also `uploadpack.hideRefs`. Even if this is false, a client
- may be able to steal objects via the techniques described in the
- "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
- best to keep private data in a separate repository.
-
-uploadpack.allowReachableSHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for an
- object that is reachable from any ref tip. However, note that
- calculating object reachability is computationally expensive.
- Defaults to `false`. Even if this is false, a client may be able
- to steal objects via the techniques described in the "SECURITY"
- section of the linkgit:gitnamespaces[7] man page; it's best to
- keep private data in a separate repository.
-
-uploadpack.allowAnySHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for any
- object at all.
- Defaults to `false`.
-
-uploadpack.keepAlive::
- When `upload-pack` has started `pack-objects`, there may be a
- quiet period while `pack-objects` prepares the pack. Normally
- it would output progress information, but if `--quiet` was used
- for the fetch, `pack-objects` will output nothing at all until
- the pack data begins. Some clients and networks may consider
- the server to be hung and give up. Setting this option instructs
- `upload-pack` to send an empty keepalive packet every
- `uploadpack.keepAlive` seconds. Setting this option to 0
- disables keepalive packets entirely. The default is 5 seconds.
-
-uploadpack.packObjectsHook::
- If this option is set, when `upload-pack` would run
- `git pack-objects` to create a packfile for a client, it will
- run this shell command instead. The `pack-objects` command and
- arguments it _would_ have run (including the `git pack-objects`
- at the beginning) are appended to the shell command. The stdin
- and stdout of the hook are treated as if `pack-objects` itself
- was run. I.e., `upload-pack` will feed input intended for
- `pack-objects` to the hook, and expects a completed packfile on
- stdout.
-+
-Note that this configuration variable is ignored if it is seen in the
-repository-level config (this is a safety measure against fetching from
-untrusted repositories).
-
-uploadpack.allowFilter::
- If this option is set, `upload-pack` will support partial
- clone and partial fetch object filtering.
-
-uploadpack.allowRefInWant::
- If this option is set, `upload-pack` will support the `ref-in-want`
- feature of the protocol version 2 `fetch` command. This feature
- is intended for the benefit of load-balanced servers which may
- not have the same view of what OIDs their refs point to due to
- replication delay.
-
-url.<base>.insteadOf::
- Any URL that starts with this value will be rewritten to
- start, instead, with <base>. In cases where some site serves a
- large number of repositories, and serves them with multiple
- access methods, and some users need to use different access
- methods, this feature allows people to specify any of the
- equivalent URLs and have Git automatically rewrite the URL to
- the best alternative for the particular user, even for a
- never-before-seen repository on the site. When more than one
- insteadOf strings match a given URL, the longest match is used.
-+
-Note that any protocol restrictions will be applied to the rewritten
-URL. If the rewrite changes the URL to use a custom protocol or remote
-helper, you may need to adjust the `protocol.*.allow` config to permit
-the request. In particular, protocols you expect to use for submodules
-must be set to `always` rather than the default of `user`. See the
-description of `protocol.allow` above.
-
-url.<base>.pushInsteadOf::
- Any URL that starts with this value will not be pushed to;
- instead, it will be rewritten to start with <base>, and the
- resulting URL will be pushed to. In cases where some site serves
- a large number of repositories, and serves them with multiple
- access methods, some of which do not allow push, this feature
- allows people to specify a pull-only URL and have Git
- automatically use an appropriate URL to push, even for a
- never-before-seen repository on the site. When more than one
- pushInsteadOf strings match a given URL, the longest match is
- used. If a remote has an explicit pushurl, Git will ignore this
- setting for that remote.
-
-user.email::
- Your email address to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
- `EMAIL` environment variables. See linkgit:git-commit-tree[1].
-
-user.name::
- Your full name to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
- environment variables. See linkgit:git-commit-tree[1].
-
-user.useConfigOnly::
- Instruct Git to avoid trying to guess defaults for `user.email`
- and `user.name`, and instead retrieve the values only from the
- configuration. For example, if you have multiple email addresses
- and would like to use a different one for each repository, then
- with this configuration option set to `true` in the global config
- along with a name, Git will prompt you to set up an email before
- making new commits in a newly cloned repository.
- Defaults to `false`.
-
-user.signingKey::
- If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
- key you want it to automatically when creating a signed tag or
- commit, you can override the default selection with this variable.
- This option is passed unchanged to gpg's --local-user parameter,
- so you may specify a key using any method that gpg supports.
-
-versionsort.prereleaseSuffix (deprecated)::
- Deprecated alias for `versionsort.suffix`. Ignored if
- `versionsort.suffix` is set.
-
-versionsort.suffix::
- Even when version sort is used in linkgit:git-tag[1], tagnames
- with the same base version but different suffixes are still sorted
- lexicographically, resulting e.g. in prerelease tags appearing
- after the main release (e.g. "1.0-rc1" after "1.0"). This
- variable can be specified to determine the sorting order of tags
- with different suffixes.
-+
-By specifying a single suffix in this variable, any tagname containing
-that suffix will appear before the corresponding main release. E.g. if
-the variable is set to "-rc", then all "1.0-rcX" tags will appear before
-"1.0". If specified multiple times, once per suffix, then the order of
-suffixes in the configuration will determine the sorting order of tagnames
-with those suffixes. E.g. if "-pre" appears before "-rc" in the
-configuration, then all "1.0-preX" tags will be listed before any
-"1.0-rcX" tags. The placement of the main release tag relative to tags
-with various suffixes can be determined by specifying the empty suffix
-among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
-"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
-are listed first, followed by "v4.8", then "v4.8-ckX" and finally
-"v4.8-bfsX".
-+
-If more than one suffixes match the same tagname, then that tagname will
-be sorted according to the suffix which starts at the earliest position in
-the tagname. If more than one different matching suffixes start at
-that earliest position, then that tagname will be sorted according to the
-longest of those suffixes.
-The sorting order between different suffixes is undefined if they are
-in multiple config files.
-
-web.browser::
- Specify a web browser that may be used by some commands.
- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
- may use it.
-
-worktree.guessRemote::
- With `add`, if no branch argument, and neither of `-b` nor
- `-B` nor `--detach` are given, the command defaults to
- creating a new branch from HEAD. If `worktree.guessRemote` is
- set to true, `worktree add` tries to find a remote-tracking
- branch whose name uniquely matches the new branch name. If
- such a branch exists, it is checked out and set as "upstream"
- for the new branch. If no such match can be found, it falls
- back to creating a new branch from the current HEAD.
+include::config/tag.txt[]
+
+include::config/transfer.txt[]
+
+include::config/uploadarchive.txt[]
+
+include::config/uploadpack.txt[]
+
+include::config/url.txt[]
+
+include::config/user.txt[]
+
+include::config/versionsort.txt[]
+
+include::config/web.txt[]
+
+include::config/worktree.txt[]