-
gitweb.category
-
gitweb.description
-
gitweb.owner
-
gitweb.url
-
See gitweb(1) for description.
-
gitweb.avatar
-
gitweb.blame
-
gitweb.grep
-
gitweb.highlight
-
gitweb.patches
-
gitweb.pickaxe
-
gitweb.remote_heads
-
gitweb.showSizes
-
gitweb.snapshot
-
See gitweb.conf(5) for description.
-
grep.lineNumber
-
If set to true, enable -n option by default.
-
grep.column
-
If set to true, enable the --column option by default.
-
grep.patternType
-
Set the default matching behavior. Using a value of basic, extended,
fixed, or perl will enable the --basic-regexp, --extended-regexp,
--fixed-strings, or --perl-regexp option accordingly, while the
value default will use the grep.extendedRegexp option to choose
between basic and extended.
-
grep.extendedRegexp
-
If set to true, enable --extended-regexp option by default. This
option is ignored when the grep.patternType option is set to a value
other than default.
-
grep.threads
-
Number of grep worker threads to use. If unset (or set to 0), Git will
use as many threads as the number of logical cores available.
-
grep.fullName
-
If set to true, enable --full-name option by default.
-
grep.fallbackToNoIndex
-
If set to true, fall back to git grep --no-index if git grep
is executed outside of a git repository. Defaults to false.
-
gpg.program
-
Use this custom program instead of "gpg" found on $PATH when
making or verifying a PGP signature. The program must support the
same command-line interface as GPG, namely, to verify a detached
signature, "gpg --verify $signature - <$file" is run, and the
program is expected to signal a good signature by exiting with
code 0. To generate an ASCII-armored detached signature, the
standard input of "gpg -bsau $key" is fed with the contents to be
signed, and the program is expected to send the result to its
standard output.
-
gpg.format
-
Specifies which key format to use when signing with --gpg-sign.
Default is "openpgp". Other possible values are "x509", "ssh".
-
gpg.<format>.program
-
Use this to customize the program used for the signing format you
chose. (see gpg.program and gpg.format) gpg.program can still
be used as a legacy synonym for gpg.openpgp.program. The default
value for gpg.x509.program is "gpgsm" and gpg.ssh.program is "ssh-keygen".
-
gpg.minTrustLevel
-
Specifies a minimum trust level for signature verification. If
this option is unset, then signature verification for merge
operations requires a key with at least marginal trust. Other
operations that perform signature verification require a key
with at least undefined trust. Setting this option overrides
the required trust-level for all operations. Supported values,
in increasing order of significance:
-
undefined
-
never
-
marginal
-
fully
-
ultimate
-
gpg.ssh.defaultKeyCommand
-
This command will be run when user.signingkey is not set and a ssh
signature is requested. On successful exit a valid ssh public key
prefixed with key:: is expected in the first line of its output.
This allows for a script doing a dynamic lookup of the correct public
key when it is impractical to statically configure user.signingKey.
For example when keys or SSH Certificates are rotated frequently or
selection of the right key depends on external factors unknown to git.
-
gpg.ssh.allowedSignersFile
-
A file containing ssh public keys which you are willing to trust.
The file consists of one or more lines of principals followed by an ssh
public key.
e.g.: user1@example.com,user2@example.com ssh-rsa AAAAX1...
See ssh-keygen(1) "ALLOWED SIGNERS" for details.
The principal is only used to identify the key and is available when
verifying a signature.
SSH has no concept of trust levels like gpg does. To be able to differentiate
between valid signatures and trusted signatures the trust level of a signature
verification is set to fully when the public key is present in the allowedSignersFile.
Otherwise the trust level is undefined and git verify-commit/tag will fail.
This file can be set to a location outside of the repository and every developer
maintains their own trust store. A central repository server could generate this
file automatically from ssh keys with push access to verify the code against.
In a corporate setting this file is probably generated at a global location
from automation that already handles developer ssh keys.
A repository that only allows signed commits can store the file
in the repository itself using a path relative to the top-level of the working tree.
This way only committers with an already valid key can add or change keys in the keyring.
Since OpensSSH 8.8 this file allows specifying a key lifetime using valid-after &
valid-before options. Git will mark signatures as valid if the signing key was
valid at the time of the signature’s creation. This allows users to change a
signing key without invalidating all previously made signatures.
Using a SSH CA key with the cert-authority option
(see ssh-keygen(1) "CERTIFICATES") is also valid.
-
gpg.ssh.revocationFile
-
Either a SSH KRL or a list of revoked public keys (without the principal prefix).
See ssh-keygen(1) for details.
If a public key is found in this file then it will always be treated
as having trust level "never" and signatures will show as invalid.
-
gui.commitMsgWidth
-
Defines how wide the commit message window is in the
git-gui(1). "75" is the default.
-
gui.diffContext
-
Specifies how many context lines should be used in calls to diff
made by the git-gui(1). The default is "5".
-
gui.displayUntracked
-
Determines if git-gui(1) shows untracked files
in the file list. The default is "true".
-
gui.encoding
-
Specifies the default character encoding to use for displaying of
file contents in git-gui(1) and gitk(1).
It can be overridden by setting the encoding attribute
for relevant files (see gitattributes(5)).
If this option is not set, the tools default to the
locale encoding.
-
gui.matchTrackingBranch
-
Determines if new branches created with git-gui(1) should
default to tracking remote branches with matching names or
not. Default: "false".
-
gui.newBranchTemplate
-
Is used as a suggested name when creating new branches using the
git-gui(1).
-
gui.pruneDuringFetch
-
"true" if git-gui(1) should prune remote-tracking branches when
performing a fetch. The default value is "false".
-
gui.trustmtime
-
Determines if git-gui(1) should trust the file modification
timestamp or not. By default the timestamps are not trusted.
-
gui.spellingDictionary
-
Specifies the dictionary used for spell checking commit messages in
the git-gui(1). When set to "none" spell checking is turned
off.
-
gui.fastCopyBlame
-
If true, git gui blame uses -C instead of -C -C for original
location detection. It makes blame significantly faster on huge
repositories at the expense of less thorough copy detection.
-
gui.copyBlameThreshold
-
Specifies the threshold to use in git gui blame original location
detection, measured in alphanumeric characters. See the
git-blame(1) manual for more information on copy detection.
-
gui.blamehistoryctx
-
Specifies the radius of history context in days to show in
gitk(1) for the selected commit, when the Show History
Context menu item is invoked from git gui blame. If this
variable is set to zero, the whole history is shown.
-
guitool.<name>.cmd
-
Specifies the shell command line to execute when the corresponding item
of the git-gui(1) Tools menu is invoked. This option is
mandatory for every tool. The command is executed from the root of
the working directory, and in the environment it receives the name of
the tool as GIT_GUITOOL, the name of the currently selected file as
FILENAME, and the name of the current branch as CUR_BRANCH (if
the head is detached, CUR_BRANCH is empty).
-
guitool.<name>.needsFile
-
Run the tool only if a diff is selected in the GUI. It guarantees
that FILENAME is not empty.
-
guitool.<name>.noConsole
-
Run the command silently, without creating a window to display its
output.
-
guitool.<name>.noRescan
-
Don’t rescan the working directory for changes after the tool
finishes execution.
-
guitool.<name>.confirm
-
Show a confirmation dialog before actually running the tool.
-
guitool.<name>.argPrompt
-
Request a string argument from the user, and pass it to the tool
through the ARGS environment variable. Since requesting an
argument implies confirmation, the confirm option has no effect
if this is enabled. If the option is set to true, yes, or 1,
the dialog uses a built-in generic prompt; otherwise the exact
value of the variable is used.
-
guitool.<name>.revPrompt
-
Request a single valid revision from the user, and set the
REVISION environment variable. In other aspects this option
is similar to argPrompt, and can be used together with it.
-
guitool.<name>.revUnmerged
-
Show only unmerged branches in the revPrompt subdialog.
This is useful for tools similar to merge or rebase, but not
for things like checkout or reset.
-
guitool.<name>.title
-
Specifies the title to use for the prompt dialog. The default
is the tool name.
-
guitool.<name>.prompt
-
Specifies the general prompt string to display at the top of
the dialog, before subsections for argPrompt and revPrompt.
The default value includes the actual command.
-
help.browser
-
Specify the browser that will be used to display help in the
web format. See git-help(1).
-
help.format
-
Override the default help format used by git-help(1).
Values man, info, web and html are supported. man is
the default. web and html are the same.
-
help.autoCorrect
-
If git detects typos and can identify exactly one valid command similar
to the error, git will try to suggest the correct command or even
run the suggestion automatically. Possible config values are:
-
0 (default): show the suggested command.
-
positive number: run the suggested command after specified
deciseconds (0.1 sec).
-
"immediate": run the suggested command immediately.
-
"prompt": show the suggestion and prompt for confirmation to run
the command.
-
"never": don’t run or show any suggested command.
-
help.htmlPath
-
Specify the path where the HTML documentation resides. File system paths
and URLs are supported. HTML pages will be prefixed with this path when
help is displayed in the web format. This defaults to the documentation
path of your Git installation.
-
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
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.proxySSLCert
-
The pathname of a file that stores a client certificate to use to authenticate
with an HTTPS proxy. Can be overridden by the GIT_PROXY_SSL_CERT environment
variable.
-
http.proxySSLKey
-
The pathname of a file that stores a private key to use to authenticate with
an HTTPS proxy. Can be overridden by the GIT_PROXY_SSL_KEY environment
variable.
-
http.proxySSLCertPasswordProtected
-
Enable Git’s password prompt for the proxy 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_PROXY_SSL_CERT_PASSWORD_PROTECTED
environment variable.
-
http.proxySSLCAInfo
-
Pathname to the file containing the certificate bundle that should be used to
verify the proxy with when using an HTTPS proxy. Can be overridden by the
GIT_PROXY_SSL_CAINFO environment variable.
-
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.version
-
Use the specified HTTP protocol version when communicating with a server.
If you want to force the default. The available and default version depend
on libcurl. Currently the possible values of
this option are:
-
http.curloptResolve
-
Hostname resolution information that will be used first by
libcurl when sending HTTP requests. This information should
be in one of the following formats:
The first format redirects all requests to the given HOST:PORT
to the provided ADDRESS(s). The second format clears all
previous config values for that HOST:PORT combination. To
allow easy overriding of all the settings inherited from the
system config, an empty value will reset all resolution
information to the empty list.
-
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. Currently the possible values of
this option are:
-
sslv2
-
sslv3
-
tlsv1
-
tlsv1.0
-
tlsv1.1
-
tlsv1.2
-
tlsv1.3
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.
Note that raising this limit is only effective for disabling chunked
transfer encoding and therefore should be used only where the remote
server or a proxy only supports HTTP/1.0 or is noncompliant with the
HTTP standard. Raising this is not, in general, an effective solution
for most push problems, but can increase memory consumption
significantly since the entire buffer is allocated even for small
pushes.
-
http.lowSpeedLimit, http.lowSpeedTime
-
If the HTTP transfer speed, in bytes per second, 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 be 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 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.
-
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 in other places in the future or in other
porcelains). See e.g. git-mailinfo(1). Defaults to utf-8.
-
i18n.logOutputEncoding
-
Character encoding the commit messages are converted to when
running git log and friends.
-
imap.folder
-
The folder to drop the mails into, which is typically the Drafts
folder. For example: "INBOX.Drafts", "INBOX/Drafts" or
"[Gmail]/Drafts". Required.
-
imap.tunnel
-
Command used to set up a tunnel to the IMAP server through which
commands will be piped instead of using a direct network connection
to the server. Required when imap.host is not set.
-
imap.host
-
A URL identifying the server. Use an imap:// prefix for non-secure
connections and an imaps:// prefix for secure connections.
Ignored when imap.tunnel is set, but required otherwise.
-
imap.user
-
The username to use when logging in to the server.
-
imap.pass
-
The password to use when logging in to the server.
-
imap.port
-
An integer port number to connect to on the server.
Defaults to 143 for imap:// hosts and 993 for imaps:// hosts.
Ignored when imap.tunnel is set.
-
imap.sslverify
-
A boolean to enable/disable verification of the server certificate
used by the SSL/TLS connection. Default is true. Ignored when
imap.tunnel is set.
-
imap.preformattedHTML
-
A boolean to enable/disable the use of html encoding when sending
a patch. An html encoded patch will be bracketed with <pre>
and have a content type of text/html. Ironically, enabling this
option causes Thunderbird to send the patch as a plain/text,
format=fixed email. Default is false.
-
imap.authMethod
-
Specify the authentication method for authenticating with the IMAP server.
If Git was built with the NO_CURL option, or if your curl version is older
than 7.34.0, or if you’re running git-imap-send with the --no-curl
option, the only supported method is CRAM-MD5. If this is not set
then git imap-send uses the basic IMAP plaintext LOGIN command.
-
include.path
-
includeIf.<condition>.path
-
Special variables to include other configuration files. See
the "CONFIGURATION FILE" section in the main
git-config(1) documentation,
specifically the "Includes" and "Conditional Includes" subsections.
-
index.recordEndOfIndexEntries
-
Specifies whether the index file should include an "End Of Index
Entry" section. This reduces index load time on multiprocessor
machines but produces a message "ignoring EOIE extension" when
reading the index using Git versions before 2.20. Defaults to
true if index.threads has been explicitly enabled, false
otherwise.
-
index.recordOffsetTable
-
Specifies whether the index file should include an "Index Entry
Offset Table" section. This reduces index load time on
multiprocessor machines but produces a message "ignoring IEOT
extension" when reading the index using Git versions before 2.20.
Defaults to true if index.threads has been explicitly enabled,
false otherwise.
-
index.sparse
-
When enabled, write the index using sparse-directory entries. This
has no effect unless core.sparseCheckout and
core.sparseCheckoutCone are both enabled. Defaults to false.
-
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
CPUs 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.
If feature.manyFiles is enabled, then the default is 4.
-
index.skipHash
-
When enabled, do not compute the trailing hash for the index file.
This accelerates Git commands that manipulate the index, such as
git add, git commit, or git status. Instead of storing the
checksum, write a trailing set of bytes with value zero, indicating
that the computation was skipped.
If you enable index.skipHash, then Git clients older than 2.13.0 will
refuse to parse the index and Git clients older than 2.40.0 will report an
error during git fsck.
-
init.templateDir
-
Specify the directory from which templates will be copied.
(See the "TEMPLATE DIRECTORY" section of git-init(1).)
-
init.defaultBranch
-
Allows overriding the default branch name e.g. when initializing
a new repository.
-
instaweb.browser
-
Specify the program that will be used to browse your working
repository in gitweb. See git-instaweb(1).
-
instaweb.httpd
-
The HTTP daemon command-line to start gitweb on your working
repository. See git-instaweb(1).
-
instaweb.local
-
If true the web server started by git-instaweb(1) will
be bound to the local IP (127.0.0.1).
-
instaweb.modulePath
-
The default module path for 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
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
git-add(1), git-checkout(1),
git-restore(1), git-commit(1),
git-reset(1), and 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 git-log(1), git-show(1), and
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 git-log(1) for details.
If the format is set to "auto:foo" and the pager is in use, format
"foo" will be used for the date format. Otherwise, "default" will
be used.
-
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.initialDecorationSet
-
By default, git log only shows decorations for certain known ref
namespaces. If all is specified, then show all refs as
decorations.
-
log.excludeDecoration
-
Exclude the specified patterns from the log decorations. This is
similar to the --decorate-refs-exclude command-line option, but
the config option can be overridden by the --decorate-refs
option.
-
log.diffMerges
-
Set diff format to be used when --diff-merges=on is
specified, see --diff-merges in git-log(1) for
details. Defaults to separate.
-
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 git-log(1) or git-whatchanged(1), which
normally hide the root commit will now show it. True by default.
-
log.showSignature
-
If true, makes git-log(1), git-show(1), and
git-whatchanged(1) assume --show-signature.
-
log.mailmap
-
If true, makes git-log(1), git-show(1), and
git-whatchanged(1) assume --use-mailmap, otherwise
assume --no-use-mailmap. True by default.
-
lsrefs.unborn
-
May be "advertise" (the default), "allow", or "ignore". If "advertise",
the server will respond to the client sending "unborn" (as described in
gitprotocol-v2(5)) and will advertise support for this feature during the
protocol v2 capability advertisement. "allow" is the same as
"advertise" except that the server will not advertise support for this
feature; this is useful for load-balanced servers that cannot be
updated atomically (for example), since the administrator could
configure "allow", then after a delay, configure "advertise".
-
mailinfo.scissors
-
If true, makes git-mailinfo(1) (and therefore
git-am(1)) act by default as if the --scissors option
was provided on the command-line. When active, this feature
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 git-shortlog(1) and 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.
-
maintenance.auto
-
This boolean config option controls whether some commands run
git maintenance run --auto after doing their normal work. Defaults
to true.
-
maintenance.strategy
-
This string config option provides a way to specify one of a few
recommended schedules for background maintenance. This only affects
which tasks are run during git maintenance run --schedule=X
commands, provided no --task=<task> arguments are provided.
Further, if a maintenance.<task>.schedule config value is set,
then that value is used instead of the one provided by
maintenance.strategy. The possible strategy strings are:
-
none: This default setting implies no tasks are run at any schedule.
-
incremental: This setting optimizes for performing small maintenance
activities that do not delete any data. This does not schedule the gc
task, but runs the prefetch and commit-graph tasks hourly, the
loose-objects and incremental-repack tasks daily, and the pack-refs
task weekly.
-
maintenance.<task>.enabled
-
This boolean config option controls whether the maintenance task
with name <task> is run when no --task option is specified to
git maintenance run. These config values are ignored if a
--task option exists. By default, only maintenance.gc.enabled
is true.
-
maintenance.<task>.schedule
-
This config option controls whether or not the given <task> runs
during a git maintenance run --schedule=<frequency> command. The
value must be one of "hourly", "daily", or "weekly".
-
maintenance.commit-graph.auto
-
This integer config option controls how often the commit-graph task
should be run as part of git maintenance run --auto. If zero, then
the commit-graph task will not run with the --auto option. A
negative value will force the task to run every time. Otherwise, a
positive value implies the command should run when the number of
reachable commits that are not in the commit-graph file is at least
the value of maintenance.commit-graph.auto. The default value is
100.
-
maintenance.loose-objects.auto
-
This integer config option controls how often the loose-objects task
should be run as part of git maintenance run --auto. If zero, then
the loose-objects task will not run with the --auto option. A
negative value will force the task to run every time. Otherwise, a
positive value implies the command should run when the number of
loose objects is at least the value of maintenance.loose-objects.auto.
The default value is 100.
-
maintenance.incremental-repack.auto
-
This integer config option controls how often the incremental-repack
task should be run as part of git maintenance run --auto. If zero,
then the incremental-repack task will not run with the --auto
option. A negative value will force the task to run every time.
Otherwise, a positive value implies the command should run when the
number of pack-files not in the multi-pack-index is at least the value
of maintenance.incremental-repack.auto. The default value is 10.
-
man.viewer
-
Specify the programs that may be used to display help in the
man format. See 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 an argument. (See 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 git-help(1).
-
merge.conflictStyle
-
Specify the style in which conflicted hunks are written out to
working tree files upon merge. The default is "merge", which
shows a <<<<<<< conflict marker, changes made by one side,
a ======= marker, changes made by the other side, and then
a >>>>>>> marker. An alternate style, "diff3", adds a |||||||
marker and the original text before the ======= marker. The
"merge" style tends to produce smaller conflict regions than diff3,
both because of the exclusion of the original text, and because
when a subset of lines match on the two sides, they are just pulled
out of the conflict region. Another alternate style, "zdiff3", is
similar to diff3 but removes matching lines on the two sides from
the conflict region when those matching lines appear near either
the beginning or end of a conflict region.
-
merge.defaultToUpstream
-
If merge is called without any commit argument, merge the upstream
branches configured for the current branch by using their last
observed values stored in their remote-tracking branches.
The values of the branch.<current branch>.merge that name the
branches at the remote named by branch.<current branch>.remote
are consulted, and then they are mapped via remote.<remote>.fetch
to their corresponding remote-tracking branches, and the tips of
these tracking branches are merged. Defaults to true.
-
merge.ff
-
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to false,
this variable tells Git to create an extra merge commit in such
a case (equivalent to giving the --no-ff option from the command
line). When set to only, only such fast-forward merges are
allowed (equivalent to giving the --ff-only option from the
command line).
-
merge.verifySignatures
-
If true, this is equivalent to the --verify-signatures command
line option. See git-merge(1) for details.
-
merge.branchdesc
-
In addition to branch names, populate the log message with
the branch description text associated with them. Defaults
to false.
-
merge.log
-
In addition to branch names, populate the log message with at
most the specified number of one-line descriptions from the
actual commits that are being merged. Defaults to false, and
true is a synonym for 20.
-
merge.suppressDest
-
By adding a glob that matches the names of integration
branches to this multi-valued configuration variable, the
default merge message computed for merges into these
integration branches will omit "into <branch name>" from
its title.
An element with an empty value can be used to clear the list
of globs accumulated from previous configuration entries.
When there is no merge.suppressDest variable defined, the
default value of master is used for backward compatibility.
-
merge.renameLimit
-
The number of files to consider in the exhaustive portion of
rename detection during a merge. If not specified, defaults
to the value of diff.renameLimit. If neither
merge.renameLimit nor diff.renameLimit are specified,
currently defaults to 7000. This setting has no effect if
rename detection is turned off.
-
merge.renames
-
Whether Git detects renames. If set to "false", rename detection
is disabled. If set to "true", basic rename detection is enabled.
Defaults to the value of diff.renames.
-
merge.directoryRenames
-
Whether Git detects directory renames, affecting what happens at
merge time to new files added to a directory on one side of
history when that directory was renamed on the other side of
history. If merge.directoryRenames is set to "false", directory
rename detection is disabled, meaning that such new files will be
left behind in the old directory. If set to "true", directory
rename detection is enabled, meaning that such new files will be
moved into the new directory. If set to "conflict", a conflict
will be reported for such paths. If merge.renames is false,
merge.directoryRenames is ignored and treated as false. Defaults
to "conflict".
-
merge.renormalize
-
Tell Git that canonical representation of files in the
repository has changed over time (e.g. earlier commits record
text files with CRLF line endings, but recent ones use LF line
endings). In such a repository, Git can convert the data
recorded in commits to a canonical form before performing a
merge to reduce unnecessary conflicts. For more information,
see section "Merging branches with differing checkin/checkout
attributes" in gitattributes(5).
-
merge.stat
-
Whether to print the diffstat between ORIG_HEAD and the merge result
at the end of the merge. True by default.
-
merge.autoStash
-
When set to true, automatically create a temporary stash entry
before the operation begins, and apply it after the operation
ends. This means that you can run merge on a dirty worktree.
However, use with care: the final stash application after a
successful merge might result in non-trivial conflicts.
This option can be overridden by the --no-autostash and
--autostash options of git-merge(1).
Defaults to false.
-
merge.tool
-
Controls which merge tool is used by git-mergetool(1).
The list below shows the valid built-in values.
Any other value is treated as a custom merge tool and requires
that a corresponding mergetool.<tool>.cmd variable is defined.
-
merge.guitool
-
Controls which merge tool is used by git-mergetool(1) when the
-g/--gui flag is specified. The list below shows the valid built-in values.
Any other value is treated as a custom merge tool and requires that a
corresponding mergetool.<guitool>.cmd variable is defined.
-
araxis
-
Use Araxis Merge (requires a graphical session)
-
bc
-
Use Beyond Compare (requires a graphical session)
-
bc3
-
Use Beyond Compare (requires a graphical session)
-
bc4
-
Use Beyond Compare (requires a graphical session)
-
codecompare
-
Use Code Compare (requires a graphical session)
-
deltawalker
-
Use DeltaWalker (requires a graphical session)
-
diffmerge
-
Use DiffMerge (requires a graphical session)
-
diffuse
-
Use Diffuse (requires a graphical session)
-
ecmerge
-
Use ECMerge (requires a graphical session)
-
emerge
-
Use Emacs' Emerge
-
examdiff
-
Use ExamDiff Pro (requires a graphical session)
-
guiffy
-
Use Guiffy’s Diff Tool (requires a graphical session)
-
gvimdiff
-
Use gVim (requires a graphical session) with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)
-
gvimdiff1
-
Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE)
-
gvimdiff2
-
Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE)
-
gvimdiff3
-
Use gVim (requires a graphical session) where only the MERGED file is shown
-
kdiff3
-
Use KDiff3 (requires a graphical session)
-
meld
-
Use Meld (requires a graphical session) with optional auto merge (see git help mergetool's CONFIGURATION section)
-
nvimdiff
-
Use Neovim with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)
-
nvimdiff1
-
Use Neovim with a 2 panes layout (LOCAL and REMOTE)
-
nvimdiff2
-
Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)
-
nvimdiff3
-
Use Neovim where only the MERGED file is shown
-
opendiff
-
Use FileMerge (requires a graphical session)
-
p4merge
-
Use HelixCore P4Merge (requires a graphical session)
-
smerge
-
Use Sublime Merge (requires a graphical session)
-
tkdiff
-
Use TkDiff (requires a graphical session)
-
tortoisemerge
-
Use TortoiseMerge (requires a graphical session)
-
vimdiff
-
Use Vim with a custom layout (see git help mergetool's BACKEND SPECIFIC HINTS section)
-
vimdiff1
-
Use Vim with a 2 panes layout (LOCAL and REMOTE)
-
vimdiff2
-
Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
-
vimdiff3
-
Use Vim where only the MERGED file is shown
-
winmerge
-
Use WinMerge (requires a graphical session)
-
xxdiff
-
Use xxdiff (requires a graphical session)
-
merge.verbosity
-
Controls the amount of output shown by the recursive merge
strategy. Level 0 outputs nothing except a final error
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
Can be overridden by the GIT_MERGE_VERBOSITY environment variable.
-
merge.<driver>.name
-
Defines a human-readable name for a custom low-level
merge driver. See gitattributes(5) for details.
-
merge.<driver>.driver
-
Defines the command that implements a custom low-level
merge driver. See gitattributes(5) for details.
-
merge.<driver>.recursive
-
Names a low-level merge driver to be used when
performing an internal merge between common ancestors.
See gitattributes(5) for details.
-
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>.hideResolved
-
Allows the user to override the global mergetool.hideResolved value
for a specific tool. See mergetool.hideResolved for the full
description.
-
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 is 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.meld.useAutoMerge
-
When the --auto-merge is given, meld will merge all non-conflicting
parts automatically, highlight the conflicting parts, and wait for
user decision. Setting mergetool.meld.useAutoMerge to true tells
Git to unconditionally use the --auto-merge option with meld.
Setting this value to auto makes git detect whether --auto-merge
is supported and will only use --auto-merge when available. A
value of false avoids using --auto-merge altogether, and is the
default value.
-
mergetool.vimdiff.layout
-
The vimdiff backend uses this variable to control how its split
windows appear. Applies even if you are using Neovim (nvim) or
gVim (gvim) as the merge tool. See BACKEND SPECIFIC HINTS section
in git-mergetool(1).
for details.
-
mergetool.hideResolved
-
During a merge, Git will automatically resolve as many conflicts as
possible and write the MERGED file containing conflict markers around
any conflicts that it cannot resolve; LOCAL and REMOTE normally
represent the versions of the file from before Git’s conflict
resolution. This flag causes LOCAL and REMOTE to be overwritten so
that only the unresolved conflicts are presented to the merge tool. Can
be configured per-tool via the mergetool.<tool>.hideResolved
configuration variable. Defaults to false.
-
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.
-
mergetool.guiDefault
-
Set true to use the merge.guitool by default (equivalent to
specifying the --gui argument), or auto to select merge.guitool
or merge.tool depending on the presence of a DISPLAY environment
variable value. The default is false, where the --gui argument
must be provided explicitly for the merge.guitool to be used.
-
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 the "NOTES MERGE STRATEGIES"
section of git-notes(1) for more information on each strategy.
This setting can be overridden by passing the --strategy option to
git-notes(1).
-
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
git-notes(1) for more information on the available strategies.
-
notes.displayRef
-
Which ref (or refs, if a glob or specified more than once), in
addition to the default set by core.notesRef or
GIT_NOTES_REF, to read notes from when showing commit
messages with the git log family of commands.
This setting can be overridden with the GIT_NOTES_DISPLAY_REF
environment variable, which must be a colon separated list of refs or
globs.
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 disabled by the --no-notes option to the git
log family of commands, or by the --notes=<ref> option accepted by
those commands.
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), if this variable is false, git will not copy
notes from the original to the rewritten commit. Defaults to
true. See also "notes.rewriteRef" below.
This setting can be overridden with the GIT_NOTES_REWRITE_REF
environment variable, which must be a colon separated list of refs or
globs.
-
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. 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.
Can be overridden with the GIT_NOTES_REWRITE_REF environment variable.
See notes.rewrite.<command> above for a further description of its format.
-
pack.window
-
The size of the window used by 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 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 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 git-repack(1).
-
pack.allowPackReuse
-
When true, and when reachability bitmaps are enabled,
pack-objects will try to send parts of the bitmapped packfile
verbatim. This can reduce memory and CPU usage to serve fetches,
but might result in sending a slightly larger pack. Defaults to
true.
-
pack.island
-
An extended regular expression configuring a set of delta
islands. See "DELTA ISLANDS" in 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 git-pack-objects(1).
-
pack.deltaCacheSize
-
The maximum memory in bytes used for caching deltas in
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
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 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 CPUs
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 is 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 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 git-repack(1). Reaching this limit results
in the creation of multiple packfiles.
Note that this option is rarely useful, and may result in a larger total
on-disk size (because Git will not store deltas between packs) and
worse runtime performance (object lookup within multiple packs is
slower than a single pack, and optimizations like reachability bitmaps
cannot cope with multiple packs).
If you need to actively run Git using smaller packfiles (e.g., because your
filesystem does not support large files), this option may help. But if
your goal is to transmit a packfile over a medium that supports limited
sizes (e.g., removable media that cannot store the whole repository),
you are likely better off creating a single large packfile and splitting
it using a generic multi-volume archive tool (e.g., Unix split).
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.useBitmapBoundaryTraversal
-
When true, Git will use an experimental algorithm for computing
reachability queries with bitmaps. Instead of building up
complete bitmaps for all of the negated tips and then OR-ing
them together, consider negated tips with existing bitmaps as
additive (i.e. OR-ing them into the result if they exist,
ignoring them otherwise), and build up a bitmap at the boundary
instead.
When using this algorithm, Git may include too many objects as a result
of not opening up trees belonging to certain UNINTERESTING commits. This
inexactness matches the non-bitmap traversal algorithm.
In many cases, this can provide a speed-up over the exact algorithm,
particularly when there is poor bitmap coverage of the negated side of
the query.
-
pack.useSparse
-
When true, git will default to using the --sparse option in
git pack-objects when the --revs option is present. This
algorithm only walks trees that appear in paths that introduce new
objects. This can have significant performance benefits when
computing a pack to send a small change. However, it is possible
that extra objects are added to the pack-file if the included
commits contain certain types of direct renames. Default is
true.
-
pack.preferBitmapTips
-
When selecting which commits will receive bitmaps, prefer a
commit at the tip of any reference that is a suffix of any value
of this configuration over any other commits in the "selection
window".
Note that setting this configuration to refs/foo does not mean that
the commits at the tips of refs/foo/bar and refs/foo/baz will
necessarily be selected. This is because commits are selected for
bitmaps from within a series of windows of variable length.
If a commit at the tip of any reference which is a suffix of any value
of this configuration is seen in a window, it is immediately given
preference over any other commit in that window.
-
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. Defaults to true.
When writing a multi-pack reachability bitmap, no new namehashes are
computed; instead, any namehashes stored in an existing bitmap are
permuted into their appropriate location when writing a new bitmap.
-
pack.writeBitmapLookupTable
-
When true, Git will include a "lookup table" section in the
bitmap index (if one is written). This table is used to defer
loading individual bitmaps as late as possible. This can be
beneficial in repositories that have relatively large bitmap
indexes. Defaults to false.
-
pack.readReverseIndex
-
When true, git will read any .rev file(s) that may be available
(see: gitformat-pack(5)). When false, the reverse index
will be generated from scratch and stored in memory. Defaults to
true.
-
pack.writeReverseIndex
-
When true, git will write a corresponding .rev file (see:
gitformat-pack(5))
for each new packfile that it writes in all places except for
git-fast-import(1) and in the bulk checkin mechanism.
Defaults to true.
-
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
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) have a
default policy of always, known-dangerous protocols (ext) have a
default policy of never, and all other protocols (including file)
have a default policy of user. Supported policies:
-
always - protocol is always able to be used.
-
never - protocol is never able to be used.
-
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.
-
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
-
If set, clients will attempt to communicate with a server
using the specified protocol version. If the server does
not support it, communication falls back to version 0.
If unset, the default is 2.
Supported versions:
-
0 - the original wire protocol.
-
1 - the original wire protocol with the addition of a version string
in the initial response from the server.
-
2 - Wire protocol version 2, see gitprotocol-v2(5).
-
pull.ff
-
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to false,
this variable tells Git to create an extra merge commit in such
a case (equivalent to giving the --no-ff option from the command
line). When set to only, only such fast-forward merges are
allowed (equivalent to giving the --ff-only option from the
command line). This setting overrides merge.ff when pulling.
-
pull.rebase
-
When true, rebase branches on top of the fetched branch, instead
of merging the default branch from the default remote when "git
pull" is run. See "branch.<name>.rebase" for setting this on a
per-branch basis.
When merges (or just m), pass the --rebase-merges option to git rebase
so that the local merge commits are included in the rebase (see
git-rebase(1) for details).
When the value is interactive (or just i), the rebase is run in interactive
mode.
NOTE: this is a possibly dangerous operation; do not use
it unless you understand the implications (see git-rebase(1)
for details).
-
pull.octopus
-
The default merge strategy to use when pulling multiple branches
at once.
-
pull.twohead
-
The default merge strategy to use when pulling a single branch.
-
push.autoSetupRemote
-
If set to "true" assume --set-upstream on default push when no
upstream tracking exists for the current branch; this option
takes effect with push.default options simple, upstream,
and current. It is useful if by default you want new branches
to be pushed to the default remote (like the behavior of
push.default=current) and you also want the upstream tracking
to be set. Workflows most likely to benefit from this option are
simple central workflows where all branches are expected to
have the same name on the remote.
-
push.default
-
Defines the action git push should take if no refspec is
given (whether from the command-line, config, or elsewhere).
Different values are well-suited for
specific workflows; for instance, in a purely central workflow
(i.e. the fetch source is equal to the push destination),
upstream is probably what you want. Possible values are:
-
nothing - do not push anything (error out) unless a refspec is
given. This is primarily meant for people who want to
avoid mistakes by always being explicit.
-
current - push the current branch to update a branch with the same
name on the receiving end. Works in both central and non-central
workflows.
-
upstream - push the current branch back to the branch whose
changes are usually integrated into the current branch (which is
called @{upstream}). This mode only makes sense if you are
pushing to the same repository you would normally pull from
(i.e. central workflow).
-
tracking - This is a deprecated synonym for upstream.
-
simple - push the current branch with the same name on the remote.
If you are working on a centralized workflow (pushing to the same repository you
pull from, which is typically origin), then you need to configure an upstream
branch with the same name.
This mode is the default since Git 2.0, and is the safest option suited for
beginners.
-
matching - push all branches having the same name on both ends.
This makes the repository you are pushing to remember the set of
branches that will be pushed out (e.g. if you always push maint
and master there and no other branches, the repository you push
to will have these two branches, and your local maint and
master will be pushed there).
To use this mode effectively, you have to make sure all the
branches you would push out are ready to be pushed out before
running git push, as the whole point of this mode is to allow you
to push all of the branches in one go. If you usually finish work
on only one branch and push out the result, while other branches are
unfinished, this mode is not for you. Also this mode is not
suitable for pushing into a shared central repository, as other
people may add new branches there, or update the tip of existing
branches outside your control.
This used to be the default, but not since Git 2.0 (simple is the
new default).
-
push.followTags
-
If set to true, enable --follow-tags option by default. You
may override this configuration at time of push by specifying
--no-follow-tags.
-
push.gpgSign
-
May be set to a boolean value, or the string if-asked. A true
value causes all pushes to be GPG signed, as if --signed is
passed to git-push(1). The string if-asked causes
pushes to be signed if the server supports it, as if
--signed=if-asked is passed to git push. A false value may
override a value from a lower-priority config file. An explicit
command-line flag always overrides this config option.
-
push.pushOption
-
When no --push-option=<option> argument is given from the
command line, git push behaves as if each <value> of
this variable is given as --push-option=<value>.
This is a multi-valued variable, and an empty value can be used in a
higher priority configuration file (e.g. .git/config in a
repository) to clear the values inherited from a lower priority
configuration files (e.g. $HOME/.gitconfig).
Example:
/etc/gitconfig
push.pushoption = a
push.pushoption = b
~/.gitconfig
push.pushoption = c
repo/.git/config
push.pushoption =
push.pushoption = b
This will result in only b (a and c are cleared).
-
push.recurseSubmodules
-
May be "check", "on-demand", "only", or "no", with the same behavior
as that of "push --recurse-submodules".
If not set, no is used by default, unless submodule.recurse is
set (in which case a true value means on-demand).
-
push.useForceIfIncludes
-
If set to "true", it is equivalent to specifying
--force-if-includes as an option to git-push(1)
in the command line. Adding --no-force-if-includes at the
time of push overrides this configuration setting.
-
push.negotiate
-
If set to "true", attempt to reduce the size of the packfile
sent by rounds of negotiation in which the client and the
server attempt to find commits in common. If "false", Git will
rely solely on the server’s ref advertisement to find commits
in common.
-
push.useBitmaps
-
If set to "false", disable use of bitmaps for "git push" even if
pack.useBitmaps is "true", without preventing other git operations
from using bitmaps. Default is true.
-
rebase.backend
-
Default backend to use for rebasing. Possible choices are
apply or merge. In the future, if the merge backend gains
all remaining capabilities of the apply backend, this setting
may become unused.
-
rebase.stat
-
Whether to show a diffstat of what changed upstream since the last
rebase. False by default.
-
rebase.autoSquash
-
If set to true enable --autosquash option by default.
-
rebase.autoStash
-
When set to true, automatically create a temporary stash entry
before the operation begins, and apply it after the operation
ends. This means that you can run rebase on a dirty worktree.
However, use with care: the final stash application after a
successful rebase might result in non-trivial conflicts.
This option can be overridden by the --no-autostash and
--autostash options of git-rebase(1).
Defaults to false.
-
rebase.updateRefs
-
If set to true enable --update-refs option by default.
-
rebase.missingCommitsCheck
-
If set to "warn", git rebase -i will print a warning if some
commits are removed (e.g. a line was deleted), however the
rebase will still proceed. If set to "error", it will print
the previous warning and stop the rebase, git rebase
--edit-todo can then be used to correct the error. If set to
"ignore", no checking is done.
To drop a commit without warning or error, use the drop
command in the todo list.
Defaults to "ignore".
-
rebase.instructionFormat
-
A format string, as specified in git-log(1), to be used for the
todo list during an interactive rebase. The format will
automatically have the commit hash prepended to the format.
-
rebase.abbreviateCommands
-
If set to true, git rebase will use abbreviated command names in the
todo list resulting in something like this:
p deadbee The oneline of the commit
p fa1afe1 The oneline of the next commit
...
pick deadbee The oneline of the commit
pick fa1afe1 The oneline of the next commit
...
-
rebase.rescheduleFailedExec
-
Automatically reschedule exec commands that failed. This only makes
sense in interactive mode (or when an --exec option was provided).
This is the same as specifying the --reschedule-failed-exec option.
-
rebase.forkPoint
-
If set to false set --no-fork-point option by default.
-
rebase.rebaseMerges
-
Whether and how to set the --rebase-merges option by default. Can
be rebase-cousins, no-rebase-cousins, or a boolean. Setting to
true or to no-rebase-cousins is equivalent to
--rebase-merges=no-rebase-cousins, setting to rebase-cousins is
equivalent to --rebase-merges=rebase-cousins, and setting to false is
equivalent to --no-rebase-merges. Passing --rebase-merges on the
command line, with or without an argument, overrides any
rebase.rebaseMerges configuration.
-
rebase.maxLabelLength
-
When generating label names from commit subjects, truncate the names to
this length. By default, the names are truncated to a little less than
NAME_MAX (to allow e.g. .lock files to be written for the
corresponding loose refs).
-
receive.advertiseAtomic
-
By default, git-receive-pack will advertise the atomic push
capability to its clients. If you don’t want to advertise this
capability, set this variable to false.
-
receive.advertisePushOptions
-
When set to true, git-receive-pack will advertise the push options
capability to its clients. False by default.
-
receive.autogc
-
By default, git-receive-pack will run "git-gc --auto" after
receiving data from git-push and updating refs. You can stop
it by setting this variable to false.
-
receive.certNonceSeed
-
By setting this variable to a string, git receive-pack
will accept a git push --signed and verify it by using
a "nonce" protected by HMAC using this string as a secret
key.
-
receive.certNonceSlop
-
When a git push --signed sends a push certificate with a
"nonce" that was issued by a receive-pack serving the same
repository within this many seconds, export the "nonce"
found in the certificate to GIT_PUSH_CERT_NONCE to the
hooks (instead of what the receive-pack asked the sending
side to include). This may allow writing checks in
pre-receive and post-receive a bit easier. Instead of
checking GIT_PUSH_CERT_NONCE_SLOP environment variable
that records by how many seconds the nonce is stale to
decide if they want to accept the certificate, they only
can check GIT_PUSH_CERT_NONCE_STATUS is OK.
-
receive.fsckObjects
-
If it is set to true, git-receive-pack will check all received
objects. See transfer.fsckObjects for what’s checked.
Defaults to false. If not set, the value of
transfer.fsckObjects is used instead.
-
receive.fsck.<msg-id>
-
Acts like fsck.<msg-id>, but is used by
git-receive-pack(1) instead of
git-fsck(1). See the fsck.<msg-id> documentation for
details.
-
receive.fsck.skipList
-
Acts like fsck.skipList, but is used by
git-receive-pack(1) instead of
git-fsck(1). See the fsck.skipList documentation for
details.
-
receive.keepAlive
-
After receiving the pack from the client, receive-pack may
produce no output (if --quiet was specified) while processing
the pack, causing some networks to drop the TCP connection.
With this option set, if receive-pack does not transmit
any data in this phase for receive.keepAlive seconds, it will
send a short keepalive packet. The default is 5 seconds; set
to 0 to disable keepalives entirely.
-
receive.unpackLimit
-
If the number of objects received in a push is below this
limit then the objects will be unpacked into loose object
files. However if the number of received objects equals or
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
especially on slow filesystems. If not set, the value of
transfer.unpackLimit is used instead.
-
receive.maxInputSize
-
If the size of the incoming pack stream is larger than this
limit, then git-receive-pack will error out, instead of
accepting the pack file. If not set or set to 0, then the size
is unlimited.
-
receive.denyDeletes
-
If set to true, git-receive-pack will deny a ref update that deletes
the ref. Use this to prevent such a ref deletion via a push.
-
receive.denyDeleteCurrent
-
If set to true, git-receive-pack will deny a ref update that
deletes the currently checked out branch of a non-bare repository.
-
receive.denyCurrentBranch
-
If set to true or "refuse", git-receive-pack will deny a ref update
to the currently checked out branch of a non-bare repository.
Such a push is potentially dangerous because it brings the HEAD
out of sync with the index and working tree. If set to "warn",
print a warning of such a push to stderr, but allow the push to
proceed. If set to false or "ignore", allow such pushes with no
message. Defaults to "refuse".
Another option is "updateInstead" which will update the working
tree if pushing into the current branch. This option is
intended for synchronizing working directories when one side is not easily
accessible via interactive ssh (e.g. a live web site, hence the requirement
that the working directory be clean). This mode also comes in handy when
developing inside a VM to test and fix code on different Operating Systems.
By default, "updateInstead" will refuse the push if the working tree or
the index have any difference from the HEAD, but the push-to-checkout
hook can be used to customize this. See githooks(5).
-
receive.denyNonFastForwards
-
If set to true, git-receive-pack will deny a ref update which is
not a fast-forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.
-
receive.hideRefs
-
This variable is the same as transfer.hideRefs, but applies
only to receive-pack (and so affects pushes, but not fetches).
An attempt to update or delete a hidden ref by git push is
rejected.
-
receive.procReceiveRefs
-
This is a multi-valued variable that defines reference prefixes
to match the commands in receive-pack. Commands matching the
prefixes will be executed by an external hook "proc-receive",
instead of the internal execute_commands function. If this
variable is not defined, the "proc-receive" hook will never be
used, and all commands will be executed by the internal
execute_commands function.
For example, if this variable is set to "refs/for", pushing to reference
such as "refs/for/master" will not create or update a reference named
"refs/for/master", but may create or update a pull request directly by
running the hook "proc-receive".
Optional modifiers can be provided in the beginning of the value to filter
commands for specific actions: create (a), modify (m), delete (d).
A ! can be included in the modifiers to negate the reference prefix entry.
E.g.:
git config --system --add receive.procReceiveRefs ad:refs/heads
git config --system --add receive.procReceiveRefs !:refs/heads
-
receive.updateServerInfo
-
If set to true, git-receive-pack will run git-update-server-info
after receiving data from git-push and updating refs.
-
receive.shallowUpdate
-
If set to true, .git/shallow can be updated when new refs
require new shallow roots. Otherwise those refs are rejected.
-
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.
-
remote.<name>.url
-
The URL of a remote repository. See git-fetch(1) or
git-push(1).
-
remote.<name>.pushurl
-
The push URL of a remote repository. See git-push(1).
-
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.
-
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.
-
remote.<name>.fetch
-
The default set of "refspec" for git-fetch(1). See
git-fetch(1).
-
remote.<name>.push
-
The default set of "refspec" for git-push(1). See
git-push(1).
-
remote.<name>.mirror
-
If true, pushing to this remote will automatically behave
as if the --mirror option was given on the command line.
-
remote.<name>.skipDefaultUpdate
-
If true, this remote will be skipped by default when updating
using git-fetch(1) or the update subcommand of
git-remote(1).
-
remote.<name>.skipFetchAll
-
If true, this remote will be skipped by default when updating
using git-fetch(1) or the update subcommand of
git-remote(1).
-
remote.<name>.receivepack
-
The default program to execute on the remote side when pushing. See
option --receive-pack of git-push(1).
-
remote.<name>.uploadpack
-
The default program to execute on the remote side when fetching. See
option --upload-pack of git-fetch-pack(1).
-
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 git-fetch(1) can
override this setting. See options --tags and --no-tags of
git-fetch(1).
-
remote.<name>.vcs
-
Setting this to a value <vcs> will cause Git to interact with
the remote with the git-remote-<vcs> helper.
-
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.
-
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
git-fetch(1).
-
remote.<name>.promisor
-
When set to true, this remote will be used to fetch promisor
objects.
-
remote.<name>.partialclonefilter
-
The filter that will be applied when fetching from this promisor remote.
Changing or clearing this value will only affect fetches for new commits.
To fetch associated objects for commits already present in the local object
database, use the --refetch option of git-fetch(1).
-
remotes.<group>
-
The list of remotes which are fetched by "git remote update
<group>". See git-remote(1).
-
repack.useDeltaBaseOffset
-
By default, 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 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 true on bare repos, false otherwise.
-
repack.updateServerInfo
-
If set to false, git-repack(1) will not run
git-update-server-info(1). Defaults to true. Can be overridden
when true by the -n option of git-repack(1).
-
repack.cruftWindow
-
repack.cruftWindowMemory
-
repack.cruftDepth
-
repack.cruftThreads
-
Parameters used by git-pack-objects(1) when generating
a cruft pack and the respective parameters are not given over
the command line. See similarly named pack.* configuration
variables for defaults and meaning.
-
rerere.autoUpdate
-
When set to true, git-rerere updates the index with the
resulting contents after it cleanly resolves conflicts using
previously recorded resolutions. 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, 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.
-
revert.reference
-
Setting this variable to true makes git revert behave
as if the --reference option is given.
-
safe.bareRepository
-
Specifies which bare repositories Git will work with. The currently
supported values are:
-
all: Git works with all bare repositories. This is the default.
-
explicit: Git only works with bare repositories specified via
the top-level --git-dir command-line option, or the GIT_DIR
environment variable (see git(1)).
If you do not use bare repositories in your workflow, then it may be
beneficial to set safe.bareRepository to explicit in your global
config. This will protect you from attacks that involve cloning a
repository that contains a bare repository and running a Git command
within that directory.
This config setting is only respected in protected configuration (see
[SCOPES]). This prevents untrusted repositories from tampering with
this value.
-
safe.directory
-
These config entries specify Git-tracked directories that are
considered safe even if they are owned by someone other than the
current user. By default, Git will refuse to even parse a Git
config of a repository owned by someone else, let alone run its
hooks, and this config setting allows users to specify exceptions,
e.g. for intentionally shared repositories (see the --shared
option in git-init(1)).
This is a multi-valued setting, i.e. you can add more than one directory
via git config --add. To reset the list of safe directories (e.g. to
override any such directories specified in the system config), add a
safe.directory entry with an empty value.
This config setting is only respected in protected configuration (see
[SCOPES]). This prevents untrusted repositories from tampering with this
value.
The value of this setting is interpolated, i.e. ~/<path> expands to a
path relative to the home directory and %(prefix)/<path> expands to a
path relative to Git’s (runtime) prefix.
To completely opt-out of this security check, set safe.directory to the
string *. This will allow all repositories to be treated as if their
directory was listed in the safe.directory list. If safe.directory=*
is set in system config and you want to re-enable this protection, then
initialize your list with an empty value before listing the repositories
that you deem safe.
As explained, Git only allows you to access repositories owned by
yourself, i.e. the user who is running Git, by default. When Git
is running as root in a non Windows platform that provides sudo,
however, git checks the SUDO_UID environment variable that sudo creates
and will allow access to the uid recorded as its value in addition to
the id from root.
This is to make it easy to perform a common sequence during installation
"make && sudo make install". A git process running under sudo runs as
root but the sudo command exports the environment variable to record
which id the original user has.
If that is not what you would prefer and want git to only trust
repositories that are owned by root instead, then you can remove
the SUDO_UID variable from root’s environment before invoking git.
-
sendemail.identity
-
A configuration identity. When given, causes values in the
sendemail.<identity> subsection to take precedence over
values in the sendemail section. The default identity is
the value of sendemail.identity.
-
sendemail.smtpEncryption
-
See git-send-email(1) for description. Note that this
setting is not subject to the identity mechanism.
-
sendemail.smtpsslcertpath
-
Path to ca-certificates (either a directory or a single file).
Set it to an empty string to disable certificate verification.
-
sendemail.<identity>.*
-
Identity-specific versions of the sendemail.* parameters
found below, taking precedence over those when this
identity is selected, through either the command-line or
sendemail.identity.
-
sendemail.multiEdit
-
If true (default), a single editor instance will be spawned to edit
files you have to edit (patches when --annotate is used, and the
summary when --compose is used). If false, files will be edited one
after the other, spawning a new editor each time.
-
sendemail.confirm
-
Sets the default for whether to confirm before sending. Must be
one of always, never, cc, compose, or auto. See --confirm
in the git-send-email(1) documentation for the meaning of these
values.
-
sendemail.aliasesFile
-
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply sendemail.aliasFileType.
-
sendemail.aliasFileType
-
Format of the file(s) specified in sendemail.aliasesFile. Must be
one of mutt, mailrc, pine, elm, gnus, or sendmail.
What an alias file in each format looks like can be found in
the documentation of the email program of the same name. The
differences and limitations from the standard formats are
described below:
-
sendmail
-
-
Quoted aliases and quoted addresses are not supported: lines that
contain a " symbol are ignored.
-
Redirection to a file (/path/name) or pipe (|command) is not
supported.
-
File inclusion (:include: /path/name) is not supported.
-
Warnings are printed on the standard error output for any
explicitly unsupported constructs, and any other lines that are not
recognized by the parser.
-
sendemail.annotate
-
sendemail.bcc
-
sendemail.cc
-
sendemail.ccCmd
-
sendemail.chainReplyTo
-
sendemail.envelopeSender
-
sendemail.from
-
sendemail.headerCmd
-
sendemail.signedoffbycc
-
sendemail.smtpPass
-
sendemail.suppresscc
-
sendemail.suppressFrom
-
sendemail.to
-
sendemail.tocmd
-
sendemail.smtpDomain
-
sendemail.smtpServer
-
sendemail.smtpServerPort
-
sendemail.smtpServerOption
-
sendemail.smtpUser
-
sendemail.thread
-
sendemail.transferEncoding
-
sendemail.validate
-
sendemail.xmailer
-
These configuration variables all provide a default for
git-send-email(1) command-line options. See its
documentation for details.
-
sendemail.signedoffcc (deprecated)
-
Deprecated alias for sendemail.signedoffbycc.
-
sendemail.smtpBatchSize
-
Number of messages to be sent per connection, after that a relogin
will happen. If the value is 0 or undefined, send all messages in
one connection.
See also the --batch-size option of git-send-email(1).
-
sendemail.smtpReloginDelay
-
Seconds to wait before reconnecting to the smtp server.
See also the --relogin-delay option of git-send-email(1).
-
sendemail.forbidSendmailVariables
-
To avoid common misconfiguration mistakes, git-send-email(1)
will abort with a warning if any configuration options for "sendmail"
exist. Set this variable to bypass the check.
-
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 git-show-branch(1).
See git-show-branch(1).
-
sideband.allowControlCharacters
-
By default, control characters that are delivered via the sideband
are NOT masked. Use this config setting to prevent potentially
unwanted ANSI escape sequences from being sent to the terminal:
-
color
-
Allow ANSI color sequences, line feeds and horizontal tabs,
but mask all other control characters.
-
false
-
Mask all control characters other than line feeds and
horizontal tabs.
-
true
-
Allow all control characters to be sent to the terminal.
This is the default.
-
sparse.expectFilesOutsideOfPatterns
-
Typically with sparse checkouts, files not matching any
sparsity patterns are marked with a SKIP_WORKTREE bit in the
index and are missing from the working tree. Accordingly, Git
will ordinarily check whether files with the SKIP_WORKTREE bit
are in fact present in the working tree contrary to
expectations. If Git finds any, it marks those paths as
present by clearing the relevant SKIP_WORKTREE bits. This
option can be used to tell Git that such
present-despite-skipped files are expected and to stop
checking for them.
The default is false, which allows Git to automatically recover
from the list of files in the index and working tree falling out of
sync.
Set this to true if you are in a setup where some external factor
relieves Git of the responsibility for maintaining the consistency
between the presence of working tree files and sparsity patterns. For
example, if you have a Git-aware virtual file system that has a robust
mechanism for keeping the working tree and the sparsity patterns up to
date based on access patterns.
Regardless of this setting, Git does not check for
present-despite-skipped files unless sparse checkout is enabled, so
this config option has no effect unless core.sparseCheckout is
true.
-
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 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 git-update-index(1).
-
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:
-
ssh - [-p port] [-4] [-6] [-o option] [username@]host command
-
simple - [username@]host command
-
plink or putty - [-P port] [-4] [-6] [username@]host command
-
tortoiseplink - [-P port] [-4] [-6] -batch [username@]host command
Except for the simple variant, command-line parameters are likely to
change as git gains new features.
-
status.relativePaths
-
By default, 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 git-status(1).
The option --no-short takes precedence over this variable.
-
status.branch
-
Set to true to enable --branch by default in git-status(1).
The option --no-branch takes precedence over this variable.
-
status.aheadBehind
-
Set to true to enable --ahead-behind and false to enable
--no-ahead-behind by default in git-status(1) for
non-porcelain status formats. Defaults to true.
-
status.displayCommentPrefix
-
If set to true, 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 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 git-status(1) and git-commit(1). Defaults to
the value of diff.renameLimit.
-
status.renames
-
Whether and how Git detects renames in git-status(1) and
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, git-status(1) will display the number of
entries currently stashed away.
Defaults to false.
-
status.showUntrackedFiles
-
By default, git-status(1) and 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 display
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 git-status(1) and 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 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.showIncludeUntracked
-
If this is set to true, the git stash show command will show
the untracked files of a stash entry. Defaults to false. See
the description of the show command in git-stash(1).
-
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 the description of the show command in git-stash(1).
-
stash.showStat
-
If this is set to true, the git stash show command without an
option will show a diffstat of the stash entry. Defaults to true.
See the description of the show command in git-stash(1).
-
submodule.<name>.url
-
The URL for a submodule. This variable is copied from the .gitmodules
file to the git config via git submodule init. The user can change
the configured URL before obtaining the submodule via git submodule
update. If neither submodule.<name>.active nor submodule.active are
set, the presence of this variable is used as a fallback to indicate
whether the submodule is of interest to git commands.
See git-submodule(1) and gitmodules(5) for details.
-
submodule.<name>.update
-
The method by which a submodule is updated by git submodule update,
which is the only affected command, others such as
git checkout --recurse-submodules are unaffected. It exists for
historical reasons, when git submodule was the only command to
interact with submodules; settings like submodule.active
and pull.rebase are more specific. It is populated by
git submodule init from the gitmodules(5) file.
See description of update command in git-submodule(1).
-
submodule.<name>.branch
-
The remote branch name for a submodule, used by git submodule
update --remote. Set this option to override the value found in
the .gitmodules file. See git-submodule(1) and
gitmodules(5) for details.
-
submodule.<name>.fetchRecurseSubmodules
-
This option can be used to control recursive fetching of this
submodule. It can be overridden by using the --[no-]recurse-submodules
command-line option to "git fetch" and "git pull".
This setting will override that from in the gitmodules(5)
file.
-
submodule.<name>.ignore
-
Defines under what circumstances "git status" and the diff family show
a submodule as modified. When set to "all", it will never be considered
modified (but it will nonetheless show up in the output of status and
commit when it has been staged), "dirty" will ignore all changes
to the submodule’s work tree and
takes only differences between the HEAD of the submodule and the commit
recorded in the superproject into account. "untracked" will additionally
let submodules with modified tracked files in their work tree show up.
Using "none" (the default when this option is not set) also shows
submodules that have untracked files in their work tree as changed.
This setting overrides any setting made in .gitmodules for this submodule,
both settings can be overridden on the command line by using the
"--ignore-submodules" option. The git submodule commands are not
affected by this setting.
-
submodule.<name>.active
-
Boolean value indicating if the submodule is of interest to git
commands. This config option takes precedence over the
submodule.active config option. See gitsubmodules(7) for
details.
-
submodule.active
-
A repeated field which contains a pathspec used to match against a
submodule’s path to determine if the submodule is of interest to git
commands. See gitsubmodules(7) for details.
-
submodule.recurse
-
A boolean indicating if commands should enable the --recurse-submodules
option by default. Defaults to false.
When set to true, it can be deactivated via the
--no-recurse-submodules option. Note that some Git commands
lacking this option may call some of the above commands affected by
submodule.recurse; for instance git remote update will call
git fetch but does not have a --no-recurse-submodules option.
For these commands a workaround is to temporarily change the
configuration value by using git -c submodule.recurse=0.
The following list shows the commands that accept
--recurse-submodules and whether they are supported by this
setting.
-
checkout, fetch, grep, pull, push, read-tree,
reset, restore and switch are always supported.
-
clone and ls-files are not supported.
-
branch is supported only if submodule.propagateBranches is
enabled
-
submodule.propagateBranches
-
[EXPERIMENTAL] A boolean that enables branching support when
using --recurse-submodules or submodule.recurse=true.
Enabling this will allow certain commands to accept
--recurse-submodules and certain commands that already accept
--recurse-submodules will now consider branches.
Defaults to false.
-
submodule.fetchJobs
-
Specifies how many submodules are fetched/cloned at the same time.
A positive integer allows up to that number of submodules fetched
in parallel. A value of 0 will give some reasonable default.
If unset, it defaults to 1.
-
submodule.alternateLocation
-
Specifies how the submodules obtain alternates when submodules are
cloned. Possible values are no, superproject.
By default no is assumed, which doesn’t add references. When the
value is set to superproject the submodule to be cloned computes
its alternates location relative to the superprojects alternate.
-
submodule.alternateErrorStrategy
-
Specifies how to treat errors with the alternates for a submodule
as computed via submodule.alternateLocation. Possible values are
ignore, info, die. Default is die. Note that if set to ignore
or info, and if there is an error with the computed alternate, the
clone proceeds as if no alternate was specified.
-
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
git-tag(1). Without the "--sort=<value>" option provided, the
value of this variable will be used as the default.
-
tag.gpgSign
-
A boolean to specify whether all tags should be GPG signed.
Use of this option when running in an automated script can
result in a large number of tags being signed. It is therefore
convenient to use an agent to avoid typing your gpg passphrase
several times. Note that this option doesn’t affect tag signing
behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
-
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
git-archive(1).