4 The Git configuration file contains a number of variables that affect
5 the Git commands' behavior. The `.git/config` file in each repository
6 is used to store the configuration for that repository, and
7 `$HOME/.gitconfig` is used to store a per-user configuration as
8 fallback values for the `.git/config` file. The file `/etc/gitconfig`
9 can be used to store a system-wide default configuration.
11 The configuration variables are used by both the Git plumbing
12 and the porcelains. The variables are divided into sections, wherein
13 the fully qualified variable name of the variable itself is the last
14 dot-separated segment and the section name is everything before the last
15 dot. The variable names are case-insensitive, allow only alphanumeric
16 characters and `-`, and must start with an alphabetic character. Some
17 variables may appear multiple times; we say then that the variable is
23 The syntax is fairly flexible and permissive; whitespaces are mostly
24 ignored. The '#' and ';' characters begin comments to the end of line,
25 blank lines are ignored.
27 The file consists of sections and variables. A section begins with
28 the name of the section in square brackets and continues until the next
29 section begins. Section names are case-insensitive. Only alphanumeric
30 characters, `-` and `.` are allowed in section names. Each variable
31 must belong to some section, which means that there must be a section
32 header before the first setting of a variable.
34 Sections can be further divided into subsections. To begin a subsection
35 put its name in double quotes, separated by space from the section name,
36 in the section header, like in the example below:
39 [section "subsection"]
43 Subsection names are case sensitive and can contain any characters except
44 newline and the null byte. Doublequote `"` and backslash can be included
45 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
46 other characters are dropped when reading; for example, `\t` is read as
47 `t` and `\0` is read as `0` Section headers cannot span multiple lines.
48 Variables may belong directly to a section or to a given subsection. You
49 can have `[section]` if you have `[section "subsection"]`, but you don't
52 There is also a deprecated `[section.subsection]` syntax. With this
53 syntax, the subsection name is converted to lower-case and is also
54 compared case sensitively. These subsection names follow the same
55 restrictions as section names.
57 All the other lines (and the remainder of the line after the section
58 header) are recognized as setting variables, in the form
59 'name = value' (or just 'name', which is a short-hand to say that
60 the variable is the boolean "true").
61 The variable names are case-insensitive, allow only alphanumeric characters
62 and `-`, and must start with an alphabetic character.
64 A line that defines a value can be continued to the next line by
65 ending it with a `\`; the backquote and the end-of-line are
66 stripped. Leading whitespaces after 'name =', the remainder of the
67 line after the first comment character '#' or ';', and trailing
68 whitespaces of the line are discarded unless they are enclosed in
69 double quotes. Internal whitespaces within the value are retained
72 Inside double quotes, double quote `"` and backslash `\` characters
73 must be escaped: use `\"` for `"` and `\\` for `\`.
75 The following escape sequences (beside `\"` and `\\`) are recognized:
76 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
77 and `\b` for backspace (BS). Other char escape sequences (including octal
78 escape sequences) are invalid.
84 The `include` and `includeIf` sections allow you to include config
85 directives from another source. These sections behave identically to
86 each other with the exception that `includeIf` sections may be ignored
87 if their condition does not evaluate to true; see "Conditional includes"
90 You can include a config file from another by setting the special
91 `include.path` (or `includeIf.*.path`) variable to the name of the file
92 to be included. The variable takes a pathname as its value, and is
93 subject to tilde expansion. These variables can be given multiple times.
95 The contents of the included file are inserted immediately, as if they
96 had been found at the location of the include directive. If the value of the
97 variable is a relative path, the path is considered to
98 be relative to the configuration file in which the include directive
99 was found. See below for examples.
104 You can include a config file from another conditionally by setting a
105 `includeIf.<condition>.path` variable to the name of the file to be
108 The condition starts with a keyword followed by a colon and some data
109 whose format and meaning depends on the keyword. Supported keywords
114 The data that follows the keyword `gitdir:` is used as a glob
115 pattern. If the location of the .git directory matches the
116 pattern, the include condition is met.
118 The .git location may be auto-discovered, or come from `$GIT_DIR`
119 environment variable. If the repository is auto discovered via a .git
120 file (e.g. from submodules, or a linked worktree), the .git location
121 would be the final location where the .git directory is, not where the
124 The pattern can contain standard globbing wildcards and two additional
125 ones, `**/` and `/**`, that can match multiple path components. Please
126 refer to linkgit:gitignore[5] for details. For convenience:
128 * If the pattern starts with `~/`, `~` will be substituted with the
129 content of the environment variable `HOME`.
131 * If the pattern starts with `./`, it is replaced with the directory
132 containing the current config file.
134 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
135 will be automatically prepended. For example, the pattern `foo/bar`
136 becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
138 * If the pattern ends with `/`, `**` will be automatically added. For
139 example, the pattern `foo/` becomes `foo/**`. In other words, it
140 matches "foo" and everything inside, recursively.
143 This is the same as `gitdir` except that matching is done
144 case-insensitively (e.g. on case-insensitive file sytems)
146 A few more notes on matching via `gitdir` and `gitdir/i`:
148 * Symlinks in `$GIT_DIR` are not resolved before matching.
150 * Both the symlink & realpath versions of paths will be matched
151 outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
152 /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
155 This was not the case in the initial release of this feature in
156 v2.13.0, which only matched the realpath version. Configuration that
157 wants to be compatible with the initial release of this feature needs
158 to either specify only the realpath version, or both versions.
160 * Note that "../" is not special and will match literally, which is
161 unlikely what you want.
168 ; Don't trust file modes
173 external = /usr/local/bin/diff-wrapper
178 merge = refs/heads/devel
182 gitProxy="ssh" for "kernel.org"
183 gitProxy=default-proxy ; for the rest
186 path = /path/to/foo.inc ; include by absolute path
187 path = foo.inc ; find "foo.inc" relative to the current file
188 path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
190 ; include if $GIT_DIR is /path/to/foo/.git
191 [includeIf "gitdir:/path/to/foo/.git"]
192 path = /path/to/foo.inc
194 ; include for all repositories inside /path/to/group
195 [includeIf "gitdir:/path/to/group/"]
196 path = /path/to/foo.inc
198 ; include for all repositories inside $HOME/to/group
199 [includeIf "gitdir:~/to/group/"]
200 path = /path/to/foo.inc
202 ; relative paths are always relative to the including
203 ; file (if the condition is true); their location is not
204 ; affected by the condition
205 [includeIf "gitdir:/path/to/group/"]
211 Values of many variables are treated as a simple string, but there
212 are variables that take values of specific types and there are rules
213 as to how to spell them.
217 When a variable is said to take a boolean value, many
218 synonyms are accepted for 'true' and 'false'; these are all
221 true;; Boolean true literals are `yes`, `on`, `true`,
222 and `1`. Also, a variable defined without `= <value>`
225 false;; Boolean false literals are `no`, `off`, `false`,
226 `0` and the empty string.
228 When converting a value to its canonical form using the `--type=bool` type
229 specifier, 'git config' will ensure that the output is "true" or
230 "false" (spelled in lowercase).
233 The value for many variables that specify various sizes can
234 be suffixed with `k`, `M`,... to mean "scale the number by
235 1024", "by 1024x1024", etc.
238 The value for a variable that takes a color is a list of
239 colors (at most two, one for foreground and one for background)
240 and attributes (as many as you want), separated by spaces.
242 The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
243 `blue`, `magenta`, `cyan` and `white`. The first color given is the
244 foreground; the second is the background.
246 Colors may also be given as numbers between 0 and 255; these use ANSI
247 256-color mode (but note that not all terminals may support this). If
248 your terminal supports it, you may also specify 24-bit RGB values as
251 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
252 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
253 The position of any attributes with respect to the colors
254 (before, after, or in between), doesn't matter. Specific attributes may
255 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
258 An empty color string produces no color effect at all. This can be used
259 to avoid coloring specific elements without disabling color entirely.
261 For git's pre-defined color slots, the attributes are meant to be reset
262 at the beginning of each item in the colored output. So setting
263 `color.decorate.branch` to `black` will paint that branch name in a
264 plain `black`, even if the previous thing on the same output line (e.g.
265 opening parenthesis before the list of branch names in `log --decorate`
266 output) is set to be painted with `bold` or some other attribute.
267 However, custom log formats may do more complicated and layered
268 coloring, and the negated forms may be useful there.
271 A variable that takes a pathname value can be given a
272 string that begins with "`~/`" or "`~user/`", and the usual
273 tilde expansion happens to such a string: `~/`
274 is expanded to the value of `$HOME`, and `~user/` to the
275 specified user's home directory.
281 Note that this list is non-comprehensive and not necessarily complete.
282 For command-specific variables, you will find a more detailed description
283 in the appropriate manual page.
285 Other git-related tools may and do use their own variables. When
286 inventing new variables for use in your own tool, make sure their
287 names do not conflict with those that are used by Git itself and
288 other popular tools, and describe them in your documentation.
290 include::config/advice.txt[]
292 include::config/core.txt[]
294 include::config/add.txt[]
296 include::config/alias.txt[]
298 include::config/am.txt[]
300 include::config/apply.txt[]
302 include::config/blame.txt[]
304 include::config/branch.txt[]
306 include::config/browser.txt[]
308 include::config/checkout.txt[]
310 include::config/clean.txt[]
312 include::config/color.txt[]
314 include::config/column.txt[]
316 include::config/commit.txt[]
318 include::config/credential.txt[]
320 include::config/completion.txt[]
322 include::config/diff.txt[]
324 include::config/difftool.txt[]
326 include::config/fastimport.txt[]
328 include::config/fetch.txt[]
330 include::config/format.txt[]
332 include::config/filter.txt[]
334 include::config/fsck.txt[]
337 The depth parameter used in the delta compression
338 algorithm used by 'git gc --aggressive'. This defaults
341 gc.aggressiveWindow::
342 The window size parameter used in the delta compression
343 algorithm used by 'git gc --aggressive'. This defaults
347 When there are approximately more than this many loose
348 objects in the repository, `git gc --auto` will pack them.
349 Some Porcelain commands use this command to perform a
350 light-weight garbage collection from time to time. The
351 default value is 6700. Setting this to 0 disables it.
354 When there are more than this many packs that are not
355 marked with `*.keep` file in the repository, `git gc
356 --auto` consolidates them into one larger pack. The
357 default value is 50. Setting this to 0 disables it.
360 Make `git gc --auto` return immediately and run in background
361 if the system supports it. Default is true.
363 gc.bigPackThreshold::
364 If non-zero, all packs larger than this limit are kept when
365 `git gc` is run. This is very similar to `--keep-base-pack`
366 except that all packs that meet the threshold are kept, not
367 just the base pack. Defaults to zero. Common unit suffixes of
368 'k', 'm', or 'g' are supported.
370 Note that if the number of kept packs is more than gc.autoPackLimit,
371 this configuration variable is ignored, all packs except the base pack
372 will be repacked. After this the number of packs should go below
373 gc.autoPackLimit and gc.bigPackThreshold should be respected again.
375 gc.writeCommitGraph::
376 If true, then gc will rewrite the commit-graph file when
377 linkgit:git-gc[1] is run. When using linkgit:git-gc[1]
378 '--auto' the commit-graph will be updated if housekeeping is
379 required. Default is false. See linkgit:git-commit-graph[1]
383 If the file gc.log exists, then `git gc --auto` will print
384 its content and exit with status zero instead of running
385 unless that file is more than 'gc.logExpiry' old. Default is
386 "1.day". See `gc.pruneExpire` for more ways to specify its
390 Running `git pack-refs` in a repository renders it
391 unclonable by Git versions prior to 1.5.1.2 over dumb
392 transports such as HTTP. This variable determines whether
393 'git gc' runs `git pack-refs`. This can be set to `notbare`
394 to enable it within all non-bare repos or it can be set to a
395 boolean value. The default is `true`.
398 When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
399 Override the grace period with this config variable. The value
400 "now" may be used to disable this grace period and always prune
401 unreachable objects immediately, or "never" may be used to
402 suppress pruning. This feature helps prevent corruption when
403 'git gc' runs concurrently with another process writing to the
404 repository; see the "NOTES" section of linkgit:git-gc[1].
406 gc.worktreePruneExpire::
407 When 'git gc' is run, it calls
408 'git worktree prune --expire 3.months.ago'.
409 This config variable can be used to set a different grace
410 period. The value "now" may be used to disable the grace
411 period and prune `$GIT_DIR/worktrees` immediately, or "never"
412 may be used to suppress pruning.
415 gc.<pattern>.reflogExpire::
416 'git reflog expire' removes reflog entries older than
417 this time; defaults to 90 days. The value "now" expires all
418 entries immediately, and "never" suppresses expiration
419 altogether. With "<pattern>" (e.g.
420 "refs/stash") in the middle the setting applies only to
421 the refs that match the <pattern>.
423 gc.reflogExpireUnreachable::
424 gc.<pattern>.reflogExpireUnreachable::
425 'git reflog expire' removes reflog entries older than
426 this time and are not reachable from the current tip;
427 defaults to 30 days. The value "now" expires all entries
428 immediately, and "never" suppresses expiration altogether.
429 With "<pattern>" (e.g. "refs/stash")
430 in the middle, the setting applies only to the refs that
434 Records of conflicted merge you resolved earlier are
435 kept for this many days when 'git rerere gc' is run.
436 You can also use more human-readable "1.month.ago", etc.
437 The default is 60 days. See linkgit:git-rerere[1].
439 gc.rerereUnresolved::
440 Records of conflicted merge you have not resolved are
441 kept for this many days when 'git rerere gc' is run.
442 You can also use more human-readable "1.month.ago", etc.
443 The default is 15 days. See linkgit:git-rerere[1].
445 include::gitcvs-config.txt[]
451 See linkgit:gitweb[1] for description.
459 gitweb.remote_heads::
462 See linkgit:gitweb.conf[5] for description.
465 If set to true, enable `-n` option by default.
468 If set to true, enable the `--column` option by default.
471 Set the default matching behavior. Using a value of 'basic', 'extended',
472 'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
473 `--fixed-strings`, or `--perl-regexp` option accordingly, while the
474 value 'default' will return to the default matching behavior.
476 grep.extendedRegexp::
477 If set to true, enable `--extended-regexp` option by default. This
478 option is ignored when the `grep.patternType` option is set to a value
479 other than 'default'.
482 Number of grep worker threads to use.
483 See `grep.threads` in linkgit:git-grep[1] for more information.
485 grep.fallbackToNoIndex::
486 If set to true, fall back to git grep --no-index if git grep
487 is executed outside of a git repository. Defaults to false.
490 Use this custom program instead of "`gpg`" found on `$PATH` when
491 making or verifying a PGP signature. The program must support the
492 same command-line interface as GPG, namely, to verify a detached
493 signature, "`gpg --verify $file - <$signature`" is run, and the
494 program is expected to signal a good signature by exiting with
495 code 0, and to generate an ASCII-armored detached signature, the
496 standard input of "`gpg -bsau $key`" is fed with the contents to be
497 signed, and the program is expected to send the result to its
501 Specifies which key format to use when signing with `--gpg-sign`.
502 Default is "openpgp" and another possible value is "x509".
504 gpg.<format>.program::
505 Use this to customize the program used for the signing format you
506 chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
507 be used as a legacy synonym for `gpg.openpgp.program`. The default
508 value for `gpg.x509.program` is "gpgsm".
510 include::gui-config.txt[]
513 Specifies the shell command line to execute when the corresponding item
514 of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
515 mandatory for every tool. The command is executed from the root of
516 the working directory, and in the environment it receives the name of
517 the tool as `GIT_GUITOOL`, the name of the currently selected file as
518 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
519 the head is detached, 'CUR_BRANCH' is empty).
521 guitool.<name>.needsFile::
522 Run the tool only if a diff is selected in the GUI. It guarantees
523 that 'FILENAME' is not empty.
525 guitool.<name>.noConsole::
526 Run the command silently, without creating a window to display its
529 guitool.<name>.noRescan::
530 Don't rescan the working directory for changes after the tool
533 guitool.<name>.confirm::
534 Show a confirmation dialog before actually running the tool.
536 guitool.<name>.argPrompt::
537 Request a string argument from the user, and pass it to the tool
538 through the `ARGS` environment variable. Since requesting an
539 argument implies confirmation, the 'confirm' option has no effect
540 if this is enabled. If the option is set to 'true', 'yes', or '1',
541 the dialog uses a built-in generic prompt; otherwise the exact
542 value of the variable is used.
544 guitool.<name>.revPrompt::
545 Request a single valid revision from the user, and set the
546 `REVISION` environment variable. In other aspects this option
547 is similar to 'argPrompt', and can be used together with it.
549 guitool.<name>.revUnmerged::
550 Show only unmerged branches in the 'revPrompt' subdialog.
551 This is useful for tools similar to merge or rebase, but not
552 for things like checkout or reset.
554 guitool.<name>.title::
555 Specifies the title to use for the prompt dialog. The default
558 guitool.<name>.prompt::
559 Specifies the general prompt string to display at the top of
560 the dialog, before subsections for 'argPrompt' and 'revPrompt'.
561 The default value includes the actual command.
564 Specify the browser that will be used to display help in the
565 'web' format. See linkgit:git-help[1].
568 Override the default help format used by linkgit:git-help[1].
569 Values 'man', 'info', 'web' and 'html' are supported. 'man' is
570 the default. 'web' and 'html' are the same.
573 Automatically correct and execute mistyped commands after
574 waiting for the given number of deciseconds (0.1 sec). If more
575 than one command can be deduced from the entered text, nothing
576 will be executed. If the value of this option is negative,
577 the corrected command will be executed immediately. If the
578 value is 0 - the command will be just shown but not executed.
582 Specify the path where the HTML documentation resides. File system paths
583 and URLs are supported. HTML pages will be prefixed with this path when
584 help is displayed in the 'web' format. This defaults to the documentation
585 path of your Git installation.
588 Override the HTTP proxy, normally configured using the 'http_proxy',
589 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
590 addition to the syntax understood by curl, it is possible to specify a
591 proxy string with a user name but no password, in which case git will
592 attempt to acquire one in the same way it does for other credentials. See
593 linkgit:gitcredentials[7] for more information. The syntax thus is
594 '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
595 on a per-remote basis; see remote.<name>.proxy
597 http.proxyAuthMethod::
598 Set the method with which to authenticate against the HTTP proxy. This
599 only takes effect if the configured proxy string contains a user name part
600 (i.e. is of the form 'user@host' or 'user@host:port'). This can be
601 overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
602 Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
603 variable. Possible values are:
606 * `anyauth` - Automatically pick a suitable authentication method. It is
607 assumed that the proxy answers an unauthenticated request with a 407
608 status code and one or more Proxy-authenticate headers with supported
609 authentication methods. This is the default.
610 * `basic` - HTTP Basic authentication
611 * `digest` - HTTP Digest authentication; this prevents the password from being
612 transmitted to the proxy in clear text
613 * `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
615 * `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
619 Attempt authentication without seeking a username or password. This
620 can be used to attempt GSS-Negotiate authentication without specifying
621 a username in the URL, as libcurl normally requires a username for
625 Control GSSAPI credential delegation. The delegation is disabled
626 by default in libcurl since version 7.21.7. Set parameter to tell
627 the server what it is allowed to delegate when it comes to user
628 credentials. Used with GSS/kerberos. Possible values are:
631 * `none` - Don't allow any delegation.
632 * `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
633 Kerberos service ticket, which is a matter of realm policy.
634 * `always` - Unconditionally allow the server to delegate.
639 Pass an additional HTTP header when communicating with a server. If
640 more than one such entry exists, all of them are added as extra
641 headers. To allow overriding the settings inherited from the system
642 config, an empty value will reset the extra headers to the empty list.
645 The pathname of a file containing previously stored cookie lines,
647 in the Git http session, if they match the server. The file format
648 of the file to read cookies from should be plain HTTP headers or
649 the Netscape/Mozilla cookie file format (see `curl(1)`).
650 NOTE that the file specified with http.cookieFile is used only as
651 input unless http.saveCookies is set.
654 If set, store cookies received during requests to the file specified by
655 http.cookieFile. Has no effect if http.cookieFile is unset.
658 The SSL version to use when negotiating an SSL connection, if you
659 want to force the default. The available and default version
660 depend on whether libcurl was built against NSS or OpenSSL and the
661 particular configuration of the crypto library in use. Internally
662 this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
663 documentation for more details on the format of this option and
664 for the ssl version supported. Actually the possible values of
676 Can be overridden by the `GIT_SSL_VERSION` environment variable.
677 To force git to use libcurl's default ssl version and ignore any
678 explicit http.sslversion option, set `GIT_SSL_VERSION` to the
682 A list of SSL ciphers to use when negotiating an SSL connection.
683 The available ciphers depend on whether libcurl was built against
684 NSS or OpenSSL and the particular configuration of the crypto
685 library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
686 option; see the libcurl documentation for more details on the format
689 Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
690 To force git to use libcurl's default cipher list and ignore any
691 explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
695 Whether to verify the SSL certificate when fetching or pushing
696 over HTTPS. Defaults to true. Can be overridden by the
697 `GIT_SSL_NO_VERIFY` environment variable.
700 File containing the SSL certificate when fetching or pushing
701 over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
705 File containing the SSL private key when fetching or pushing
706 over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
709 http.sslCertPasswordProtected::
710 Enable Git's password prompt for the SSL certificate. Otherwise
711 OpenSSL will prompt the user, possibly many times, if the
712 certificate or private key is encrypted. Can be overridden by the
713 `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
716 File containing the certificates to verify the peer with when
717 fetching or pushing over HTTPS. Can be overridden by the
718 `GIT_SSL_CAINFO` environment variable.
721 Path containing files with the CA certificates to verify the peer
722 with when fetching or pushing over HTTPS. Can be overridden
723 by the `GIT_SSL_CAPATH` environment variable.
726 Name of the SSL backend to use (e.g. "openssl" or "schannel").
727 This option is ignored if cURL lacks support for choosing the SSL
730 http.schannelCheckRevoke::
731 Used to enforce or disable certificate revocation checks in cURL
732 when http.sslBackend is set to "schannel". Defaults to `true` if
733 unset. Only necessary to disable this if Git consistently errors
734 and the message is about checking the revocation status of a
735 certificate. This option is ignored if cURL lacks support for
736 setting the relevant SSL option at runtime.
738 http.schannelUseSSLCAInfo::
739 As of cURL v7.60.0, the Secure Channel backend can use the
740 certificate bundle provided via `http.sslCAInfo`, but that would
741 override the Windows Certificate Store. Since this is not desirable
742 by default, Git will tell cURL not to use that bundle by default
743 when the `schannel` backend was configured via `http.sslBackend`,
744 unless `http.schannelUseSSLCAInfo` overrides this behavior.
747 Public key of the https service. It may either be the filename of
748 a PEM or DER encoded public key file or a string starting with
749 'sha256//' followed by the base64 encoded sha256 hash of the
750 public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
751 exit with an error if this option is set but not supported by
755 Attempt to use AUTH SSL/TLS and encrypted data transfers
756 when connecting via regular FTP protocol. This might be needed
757 if the FTP server requires it for security reasons or you wish
758 to connect securely whenever remote FTP server supports it.
759 Default is false since it might trigger certificate verification
760 errors on misconfigured servers.
763 How many HTTP requests to launch in parallel. Can be overridden
764 by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
767 The number of curl sessions (counted across slots) to be kept across
768 requests. They will not be ended with curl_easy_cleanup() until
769 http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
770 value will be capped at 1. Defaults to 1.
773 Maximum size in bytes of the buffer used by smart HTTP
774 transports when POSTing data to the remote system.
775 For requests larger than this buffer size, HTTP/1.1 and
776 Transfer-Encoding: chunked is used to avoid creating a
777 massive pack file locally. Default is 1 MiB, which is
778 sufficient for most requests.
780 http.lowSpeedLimit, http.lowSpeedTime::
781 If the HTTP transfer speed is less than 'http.lowSpeedLimit'
782 for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
783 Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
784 `GIT_HTTP_LOW_SPEED_TIME` environment variables.
787 A boolean which disables using of EPSV ftp command by curl.
788 This can helpful with some "poor" ftp servers which don't
789 support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV`
790 environment variable. Default is false (curl will use EPSV).
793 The HTTP USER_AGENT string presented to an HTTP server. The default
794 value represents the version of the client Git such as git/1.7.1.
795 This option allows you to override this value to a more common value
796 such as Mozilla/4.0. This may be necessary, for instance, if
797 connecting through a firewall that restricts HTTP connections to a set
798 of common USER_AGENT strings (but not including those like git/1.7.1).
799 Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.
801 http.followRedirects::
802 Whether git should follow HTTP redirects. If set to `true`, git
803 will transparently follow any redirect issued by a server it
804 encounters. If set to `false`, git will treat all redirects as
805 errors. If set to `initial`, git will follow redirects only for
806 the initial request to a remote, but not for subsequent
807 follow-up HTTP requests. Since git uses the redirected URL as
808 the base for the follow-up requests, this is generally
809 sufficient. The default is `initial`.
812 Any of the http.* options above can be applied selectively to some URLs.
813 For a config key to match a URL, each element of the config key is
814 compared to that of the URL, in the following order:
817 . Scheme (e.g., `https` in `https://example.com/`). This field
818 must match exactly between the config key and the URL.
820 . Host/domain name (e.g., `example.com` in `https://example.com/`).
821 This field must match between the config key and the URL. It is
822 possible to specify a `*` as part of the host name to match all subdomains
823 at this level. `https://*.example.com/` for example would match
824 `https://foo.example.com/`, but not `https://foo.bar.example.com/`.
826 . Port number (e.g., `8080` in `http://example.com:8080/`).
827 This field must match exactly between the config key and the URL.
828 Omitted port numbers are automatically converted to the correct
829 default for the scheme before matching.
831 . Path (e.g., `repo.git` in `https://example.com/repo.git`). The
832 path field of the config key must match the path field of the URL
833 either exactly or as a prefix of slash-delimited path elements. This means
834 a config key with path `foo/` matches URL path `foo/bar`. A prefix can only
835 match on a slash (`/`) boundary. Longer matches take precedence (so a config
836 key with path `foo/bar` is a better match to URL path `foo/bar` than a config
837 key with just path `foo/`).
839 . User name (e.g., `user` in `https://user@example.com/repo.git`). If
840 the config key has a user name it must match the user name in the
841 URL exactly. If the config key does not have a user name, that
842 config key will match a URL with any user name (including none),
843 but at a lower precedence than a config key with a user name.
846 The list above is ordered by decreasing precedence; a URL that matches
847 a config key's path is preferred to one that matches its user name. For example,
848 if the URL is `https://user@example.com/foo/bar` a config key match of
849 `https://example.com/foo` will be preferred over a config key match of
850 `https://user@example.com`.
852 All URLs are normalized before attempting any matching (the password part,
853 if embedded in the URL, is always ignored for matching purposes) so that
854 equivalent URLs that are simply spelled differently will match properly.
855 Environment variable settings always override any matches. The URLs that are
856 matched against are those given directly to Git commands. This means any URLs
857 visited as a result of a redirection do not participate in matching.
860 By default, Git determines the command line arguments to use
861 based on the basename of the configured SSH command (configured
862 using the environment variable `GIT_SSH` or `GIT_SSH_COMMAND` or
863 the config setting `core.sshCommand`). If the basename is
864 unrecognized, Git will attempt to detect support of OpenSSH
865 options by first invoking the configured SSH command with the
866 `-G` (print configuration) option and will subsequently use
867 OpenSSH options (if that is successful) or no options besides
868 the host and remote command (if it fails).
870 The config variable `ssh.variant` can be set to override this detection.
871 Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
872 `tortoiseplink`, `simple` (no options except the host and remote command).
873 The default auto-detection can be explicitly requested using the value
874 `auto`. Any other value is treated as `ssh`. This setting can also be
875 overridden via the environment variable `GIT_SSH_VARIANT`.
877 The current command-line parameters used for each variant are as
882 * `ssh` - [-p port] [-4] [-6] [-o option] [username@]host command
884 * `simple` - [username@]host command
886 * `plink` or `putty` - [-P port] [-4] [-6] [username@]host command
888 * `tortoiseplink` - [-P port] [-4] [-6] -batch [username@]host command
892 Except for the `simple` variant, command-line parameters are likely to
893 change as git gains new features.
895 i18n.commitEncoding::
896 Character encoding the commit messages are stored in; Git itself
897 does not care per se, but this information is necessary e.g. when
898 importing commits from emails or in the gitk graphical history
899 browser (and possibly at other places in the future or in other
900 porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
902 i18n.logOutputEncoding::
903 Character encoding the commit messages are converted to when
904 running 'git log' and friends.
907 The configuration variables in the 'imap' section are described
908 in linkgit:git-imap-send[1].
911 Specifies the number of threads to spawn when loading the index.
912 This is meant to reduce index load time on multiprocessor machines.
913 Specifying 0 or 'true' will cause Git to auto-detect the number of
914 CPU's and set the number of threads accordingly. Specifying 1 or
915 'false' will disable multithreading. Defaults to 'true'.
918 Specify the version with which new index files should be
919 initialized. This does not affect existing repositories.
922 Specify the directory from which templates will be copied.
923 (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
926 Specify the program that will be used to browse your working
927 repository in gitweb. See linkgit:git-instaweb[1].
930 The HTTP daemon command-line to start gitweb on your working
931 repository. See linkgit:git-instaweb[1].
934 If true the web server started by linkgit:git-instaweb[1] will
935 be bound to the local IP (127.0.0.1).
937 instaweb.modulePath::
938 The default module path for linkgit:git-instaweb[1] to use
939 instead of /usr/lib/apache2/modules. Only used if httpd
943 The port number to bind the gitweb httpd to. See
944 linkgit:git-instaweb[1].
946 interactive.singleKey::
947 In interactive commands, allow the user to provide one-letter
948 input with a single key (i.e., without hitting enter).
949 Currently this is used by the `--patch` mode of
950 linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
951 linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
952 setting is silently ignored if portable keystroke input
953 is not available; requires the Perl module Term::ReadKey.
955 interactive.diffFilter::
956 When an interactive command (such as `git add --patch`) shows
957 a colorized diff, git will pipe the diff through the shell
958 command defined by this configuration variable. The command may
959 mark up the diff further for human consumption, provided that it
960 retains a one-to-one correspondence with the lines in the
961 original diff. Defaults to disabled (no filtering).
964 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
965 linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
966 override this option with `--no-abbrev-commit`.
969 Set the default date-time mode for the 'log' command.
970 Setting a value for log.date is similar to using 'git log''s
971 `--date` option. See linkgit:git-log[1] for details.
974 Print out the ref names of any commits that are shown by the log
975 command. If 'short' is specified, the ref name prefixes 'refs/heads/',
976 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
977 specified, the full ref name (including prefix) will be printed.
978 If 'auto' is specified, then if the output is going to a terminal,
979 the ref names are shown as if 'short' were given, otherwise no ref
980 names are shown. This is the same as the `--decorate` option
984 If `true`, `git log` will act as if the `--follow` option was used when
985 a single <path> is given. This has the same limitations as `--follow`,
986 i.e. it cannot be used to follow multiple files and does not work well
987 on non-linear history.
990 A list of colors, separated by commas, that can be used to draw
991 history lines in `git log --graph`.
994 If true, the initial commit will be shown as a big creation event.
995 This is equivalent to a diff against an empty tree.
996 Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
997 normally hide the root commit will now show it. True by default.
1000 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
1001 linkgit:git-whatchanged[1] assume `--show-signature`.
1004 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
1005 linkgit:git-whatchanged[1] assume `--use-mailmap`.
1008 If true, makes linkgit:git-mailinfo[1] (and therefore
1009 linkgit:git-am[1]) act by default as if the --scissors option
1010 was provided on the command-line. When active, this features
1011 removes everything from the message body before a scissors
1012 line (i.e. consisting mainly of ">8", "8<" and "-").
1015 The location of an augmenting mailmap file. The default
1016 mailmap, located in the root of the repository, is loaded
1017 first, then the mailmap file pointed to by this variable.
1018 The location of the mailmap file may be in a repository
1019 subdirectory, or somewhere outside of the repository itself.
1020 See linkgit:git-shortlog[1] and linkgit:git-blame[1].
1023 Like `mailmap.file`, but consider the value as a reference to a
1024 blob in the repository. If both `mailmap.file` and
1025 `mailmap.blob` are given, both are parsed, with entries from
1026 `mailmap.file` taking precedence. In a bare repository, this
1027 defaults to `HEAD:.mailmap`. In a non-bare repository, it
1031 Specify the programs that may be used to display help in the
1032 'man' format. See linkgit:git-help[1].
1035 Specify the command to invoke the specified man viewer. The
1036 specified command is evaluated in shell with the man page
1037 passed as argument. (See linkgit:git-help[1].)
1040 Override the path for the given tool that may be used to
1041 display help in the 'man' format. See linkgit:git-help[1].
1043 include::merge-config.txt[]
1045 mergetool.<tool>.path::
1046 Override the path for the given tool. This is useful in case
1047 your tool is not in the PATH.
1049 mergetool.<tool>.cmd::
1050 Specify the command to invoke the specified merge tool. The
1051 specified command is evaluated in shell with the following
1052 variables available: 'BASE' is the name of a temporary file
1053 containing the common base of the files to be merged, if available;
1054 'LOCAL' is the name of a temporary file containing the contents of
1055 the file on the current branch; 'REMOTE' is the name of a temporary
1056 file containing the contents of the file from the branch being
1057 merged; 'MERGED' contains the name of the file to which the merge
1058 tool should write the results of a successful merge.
1060 mergetool.<tool>.trustExitCode::
1061 For a custom merge command, specify whether the exit code of
1062 the merge command can be used to determine whether the merge was
1063 successful. If this is not set to true then the merge target file
1064 timestamp is checked and the merge assumed to have been successful
1065 if the file has been updated, otherwise the user is prompted to
1066 indicate the success of the merge.
1068 mergetool.meld.hasOutput::
1069 Older versions of `meld` do not support the `--output` option.
1070 Git will attempt to detect whether `meld` supports `--output`
1071 by inspecting the output of `meld --help`. Configuring
1072 `mergetool.meld.hasOutput` will make Git skip these checks and
1073 use the configured value instead. Setting `mergetool.meld.hasOutput`
1074 to `true` tells Git to unconditionally use the `--output` option,
1075 and `false` avoids using `--output`.
1077 mergetool.keepBackup::
1078 After performing a merge, the original file with conflict markers
1079 can be saved as a file with a `.orig` extension. If this variable
1080 is set to `false` then this file is not preserved. Defaults to
1081 `true` (i.e. keep the backup files).
1083 mergetool.keepTemporaries::
1084 When invoking a custom merge tool, Git uses a set of temporary
1085 files to pass to the tool. If the tool returns an error and this
1086 variable is set to `true`, then these temporary files will be
1087 preserved, otherwise they will be removed after the tool has
1088 exited. Defaults to `false`.
1090 mergetool.writeToTemp::
1091 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
1092 conflicting files in the worktree by default. Git will attempt
1093 to use a temporary directory for these files when set `true`.
1094 Defaults to `false`.
1097 Prompt before each invocation of the merge resolution program.
1099 notes.mergeStrategy::
1100 Which merge strategy to choose by default when resolving notes
1101 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
1102 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
1103 section of linkgit:git-notes[1] for more information on each strategy.
1105 notes.<name>.mergeStrategy::
1106 Which merge strategy to choose when doing a notes merge into
1107 refs/notes/<name>. This overrides the more general
1108 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
1109 linkgit:git-notes[1] for more information on the available strategies.
1112 The (fully qualified) refname from which to show notes when
1113 showing commit messages. The value of this variable can be set
1114 to a glob, in which case notes from all matching refs will be
1115 shown. You may also specify this configuration variable
1116 several times. A warning will be issued for refs that do not
1117 exist, but a glob that does not match any refs is silently
1120 This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
1121 environment variable, which must be a colon separated list of refs or
1124 The effective value of "core.notesRef" (possibly overridden by
1125 GIT_NOTES_REF) is also implicitly added to the list of refs to be
1128 notes.rewrite.<command>::
1129 When rewriting commits with <command> (currently `amend` or
1130 `rebase`) and this variable is set to `true`, Git
1131 automatically copies your notes from the original to the
1132 rewritten commit. Defaults to `true`, but see
1133 "notes.rewriteRef" below.
1136 When copying notes during a rewrite (see the
1137 "notes.rewrite.<command>" option), determines what to do if
1138 the target commit already has a note. Must be one of
1139 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
1140 Defaults to `concatenate`.
1142 This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
1143 environment variable.
1146 When copying notes during a rewrite, specifies the (fully
1147 qualified) ref whose notes should be copied. The ref may be a
1148 glob, in which case notes in all matching refs will be copied.
1149 You may also specify this configuration several times.
1151 Does not have a default value; you must configure this variable to
1152 enable note rewriting. Set it to `refs/notes/commits` to enable
1153 rewriting for the default commit notes.
1155 This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
1156 environment variable, which must be a colon separated list of refs or
1160 The size of the window used by linkgit:git-pack-objects[1] when no
1161 window size is given on the command line. Defaults to 10.
1164 The maximum delta depth used by linkgit:git-pack-objects[1] when no
1165 maximum depth is given on the command line. Defaults to 50.
1166 Maximum value is 4095.
1169 The maximum size of memory that is consumed by each thread
1170 in linkgit:git-pack-objects[1] for pack window memory when
1171 no limit is given on the command line. The value can be
1172 suffixed with "k", "m", or "g". When left unconfigured (or
1173 set explicitly to 0), there will be no limit.
1176 An integer -1..9, indicating the compression level for objects
1177 in a pack file. -1 is the zlib default. 0 means no
1178 compression, and 1..9 are various speed/size tradeoffs, 9 being
1179 slowest. If not set, defaults to core.compression. If that is
1180 not set, defaults to -1, the zlib default, which is "a default
1181 compromise between speed and compression (currently equivalent
1184 Note that changing the compression level will not automatically recompress
1185 all existing objects. You can force recompression by passing the -F option
1186 to linkgit:git-repack[1].
1189 An extended regular expression configuring a set of delta
1190 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
1194 Specify an island name which gets to have its objects be
1195 packed first. This creates a kind of pseudo-pack at the front
1196 of one pack, so that the objects from the specified island are
1197 hopefully faster to copy into any pack that should be served
1198 to a user requesting these objects. In practice this means
1199 that the island specified should likely correspond to what is
1200 the most commonly cloned in the repo. See also "DELTA ISLANDS"
1201 in linkgit:git-pack-objects[1].
1203 pack.deltaCacheSize::
1204 The maximum memory in bytes used for caching deltas in
1205 linkgit:git-pack-objects[1] before writing them out to a pack.
1206 This cache is used to speed up the writing object phase by not
1207 having to recompute the final delta result once the best match
1208 for all objects is found. Repacking large repositories on machines
1209 which are tight with memory might be badly impacted by this though,
1210 especially if this cache pushes the system into swapping.
1211 A value of 0 means no limit. The smallest size of 1 byte may be
1212 used to virtually disable this cache. Defaults to 256 MiB.
1214 pack.deltaCacheLimit::
1215 The maximum size of a delta, that is cached in
1216 linkgit:git-pack-objects[1]. This cache is used to speed up the
1217 writing object phase by not having to recompute the final delta
1218 result once the best match for all objects is found.
1219 Defaults to 1000. Maximum value is 65535.
1222 Specifies the number of threads to spawn when searching for best
1223 delta matches. This requires that linkgit:git-pack-objects[1]
1224 be compiled with pthreads otherwise this option is ignored with a
1225 warning. This is meant to reduce packing time on multiprocessor
1226 machines. The required amount of memory for the delta search window
1227 is however multiplied by the number of threads.
1228 Specifying 0 will cause Git to auto-detect the number of CPU's
1229 and set the number of threads accordingly.
1232 Specify the default pack index version. Valid values are 1 for
1233 legacy pack index used by Git versions prior to 1.5.2, and 2 for
1234 the new pack index with capabilities for packs larger than 4 GB
1235 as well as proper protection against the repacking of corrupted
1236 packs. Version 2 is the default. Note that version 2 is enforced
1237 and this config option ignored whenever the corresponding pack is
1240 If you have an old Git that does not understand the version 2 `*.idx` file,
1241 cloning or fetching over a non native protocol (e.g. "http")
1242 that will copy both `*.pack` file and corresponding `*.idx` file from the
1243 other side may give you a repository that cannot be accessed with your
1244 older version of Git. If the `*.pack` file is smaller than 2 GB, however,
1245 you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
1248 pack.packSizeLimit::
1249 The maximum size of a pack. This setting only affects
1250 packing to a file when repacking, i.e. the git:// protocol
1251 is unaffected. It can be overridden by the `--max-pack-size`
1252 option of linkgit:git-repack[1]. Reaching this limit results
1253 in the creation of multiple packfiles; which in turn prevents
1254 bitmaps from being created.
1255 The minimum size allowed is limited to 1 MiB.
1256 The default is unlimited.
1257 Common unit suffixes of 'k', 'm', or 'g' are
1261 When true, git will use pack bitmaps (if available) when packing
1262 to stdout (e.g., during the server side of a fetch). Defaults to
1263 true. You should not generally need to turn this off unless
1264 you are debugging pack bitmaps.
1266 pack.writeBitmaps (deprecated)::
1267 This is a deprecated synonym for `repack.writeBitmaps`.
1269 pack.writeBitmapHashCache::
1270 When true, git will include a "hash cache" section in the bitmap
1271 index (if one is written). This cache can be used to feed git's
1272 delta heuristics, potentially leading to better deltas between
1273 bitmapped and non-bitmapped objects (e.g., when serving a fetch
1274 between an older, bitmapped pack and objects that have been
1275 pushed since the last gc). The downside is that it consumes 4
1276 bytes per object of disk space, and that JGit's bitmap
1277 implementation does not understand it, causing it to complain if
1278 Git and JGit are used on the same repository. Defaults to false.
1281 If the value is boolean, turns on or off pagination of the
1282 output of a particular Git subcommand when writing to a tty.
1283 Otherwise, turns on pagination for the subcommand using the
1284 pager specified by the value of `pager.<cmd>`. If `--paginate`
1285 or `--no-pager` is specified on the command line, it takes
1286 precedence over this option. To disable pagination for all
1287 commands, set `core.pager` or `GIT_PAGER` to `cat`.
1290 Alias for a --pretty= format string, as specified in
1291 linkgit:git-log[1]. Any aliases defined here can be used just
1292 as the built-in pretty formats could. For example,
1293 running `git config pretty.changelog "format:* %H %s"`
1294 would cause the invocation `git log --pretty=changelog`
1295 to be equivalent to running `git log "--pretty=format:* %H %s"`.
1296 Note that an alias with the same name as a built-in format
1297 will be silently ignored.
1300 If set, provide a user defined default policy for all protocols which
1301 don't explicitly have a policy (`protocol.<name>.allow`). By default,
1302 if unset, known-safe protocols (http, https, git, ssh, file) have a
1303 default policy of `always`, known-dangerous protocols (ext) have a
1304 default policy of `never`, and all other protocols have a default
1305 policy of `user`. Supported policies:
1309 * `always` - protocol is always able to be used.
1311 * `never` - protocol is never able to be used.
1313 * `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
1314 either unset or has a value of 1. This policy should be used when you want a
1315 protocol to be directly usable by the user but don't want it used by commands which
1316 execute clone/fetch/push commands without user input, e.g. recursive
1317 submodule initialization.
1321 protocol.<name>.allow::
1322 Set a policy to be used by protocol `<name>` with clone/fetch/push
1323 commands. See `protocol.allow` above for the available policies.
1325 The protocol names currently used by git are:
1328 - `file`: any local file-based path (including `file://` URLs,
1331 - `git`: the anonymous git protocol over a direct TCP
1332 connection (or proxy, if configured)
1334 - `ssh`: git over ssh (including `host:path` syntax,
1337 - `http`: git over http, both "smart http" and "dumb http".
1338 Note that this does _not_ include `https`; if you want to configure
1339 both, you must do so individually.
1341 - any external helpers are named by their protocol (e.g., use
1342 `hg` to allow the `git-remote-hg` helper)
1346 Experimental. If set, clients will attempt to communicate with a
1347 server using the specified protocol version. If unset, no
1348 attempt will be made by the client to communicate using a
1349 particular protocol version, this results in protocol version 0
1355 * `0` - the original wire protocol.
1357 * `1` - the original wire protocol with the addition of a version string
1358 in the initial response from the server.
1360 * `2` - link:technical/protocol-v2.html[wire protocol version 2].
1364 include::pull-config.txt[]
1366 include::push-config.txt[]
1368 include::rebase-config.txt[]
1370 include::receive-config.txt[]
1372 remote.pushDefault::
1373 The remote to push to by default. Overrides
1374 `branch.<name>.remote` for all branches, and is overridden by
1375 `branch.<name>.pushRemote` for specific branches.
1378 The URL of a remote repository. See linkgit:git-fetch[1] or
1379 linkgit:git-push[1].
1381 remote.<name>.pushurl::
1382 The push URL of a remote repository. See linkgit:git-push[1].
1384 remote.<name>.proxy::
1385 For remotes that require curl (http, https and ftp), the URL to
1386 the proxy to use for that remote. Set to the empty string to
1387 disable proxying for that remote.
1389 remote.<name>.proxyAuthMethod::
1390 For remotes that require curl (http, https and ftp), the method to use for
1391 authenticating against the proxy in use (probably set in
1392 `remote.<name>.proxy`). See `http.proxyAuthMethod`.
1394 remote.<name>.fetch::
1395 The default set of "refspec" for linkgit:git-fetch[1]. See
1396 linkgit:git-fetch[1].
1398 remote.<name>.push::
1399 The default set of "refspec" for linkgit:git-push[1]. See
1400 linkgit:git-push[1].
1402 remote.<name>.mirror::
1403 If true, pushing to this remote will automatically behave
1404 as if the `--mirror` option was given on the command line.
1406 remote.<name>.skipDefaultUpdate::
1407 If true, this remote will be skipped by default when updating
1408 using linkgit:git-fetch[1] or the `update` subcommand of
1409 linkgit:git-remote[1].
1411 remote.<name>.skipFetchAll::
1412 If true, this remote will be skipped by default when updating
1413 using linkgit:git-fetch[1] or the `update` subcommand of
1414 linkgit:git-remote[1].
1416 remote.<name>.receivepack::
1417 The default program to execute on the remote side when pushing. See
1418 option --receive-pack of linkgit:git-push[1].
1420 remote.<name>.uploadpack::
1421 The default program to execute on the remote side when fetching. See
1422 option --upload-pack of linkgit:git-fetch-pack[1].
1424 remote.<name>.tagOpt::
1425 Setting this value to --no-tags disables automatic tag following when
1426 fetching from remote <name>. Setting it to --tags will fetch every
1427 tag from remote <name>, even if they are not reachable from remote
1428 branch heads. Passing these flags directly to linkgit:git-fetch[1] can
1429 override this setting. See options --tags and --no-tags of
1430 linkgit:git-fetch[1].
1433 Setting this to a value <vcs> will cause Git to interact with
1434 the remote with the git-remote-<vcs> helper.
1436 remote.<name>.prune::
1437 When set to true, fetching from this remote by default will also
1438 remove any remote-tracking references that no longer exist on the
1439 remote (as if the `--prune` option was given on the command line).
1440 Overrides `fetch.prune` settings, if any.
1442 remote.<name>.pruneTags::
1443 When set to true, fetching from this remote by default will also
1444 remove any local tags that no longer exist on the remote if pruning
1445 is activated in general via `remote.<name>.prune`, `fetch.prune` or
1446 `--prune`. Overrides `fetch.pruneTags` settings, if any.
1448 See also `remote.<name>.prune` and the PRUNING section of
1449 linkgit:git-fetch[1].
1452 The list of remotes which are fetched by "git remote update
1453 <group>". See linkgit:git-remote[1].
1455 repack.useDeltaBaseOffset::
1456 By default, linkgit:git-repack[1] creates packs that use
1457 delta-base offset. If you need to share your repository with
1458 Git older than version 1.4.4, either directly or via a dumb
1459 protocol such as http, then you need to set this option to
1460 "false" and repack. Access from old Git versions over the
1461 native protocol are unaffected by this option.
1463 repack.packKeptObjects::
1464 If set to true, makes `git repack` act as if
1465 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
1466 details. Defaults to `false` normally, but `true` if a bitmap
1467 index is being written (either via `--write-bitmap-index` or
1468 `repack.writeBitmaps`).
1470 repack.useDeltaIslands::
1471 If set to true, makes `git repack` act as if `--delta-islands`
1472 was passed. Defaults to `false`.
1474 repack.writeBitmaps::
1475 When true, git will write a bitmap index when packing all
1476 objects to disk (e.g., when `git repack -a` is run). This
1477 index can speed up the "counting objects" phase of subsequent
1478 packs created for clones and fetches, at the cost of some disk
1479 space and extra time spent on the initial repack. This has
1480 no effect if multiple packfiles are created.
1484 When set to true, `git-rerere` updates the index with the
1485 resulting contents after it cleanly resolves conflicts using
1486 previously recorded resolution. Defaults to false.
1489 Activate recording of resolved conflicts, so that identical
1490 conflict hunks can be resolved automatically, should they be
1491 encountered again. By default, linkgit:git-rerere[1] is
1492 enabled if there is an `rr-cache` directory under the
1493 `$GIT_DIR`, e.g. if "rerere" was previously used in the
1497 When set to true, 'git reset' will default to the '--quiet' option.
1499 include::sendemail-config.txt[]
1502 Text editor used by `git rebase -i` for editing the rebase instruction file.
1503 The value is meant to be interpreted by the shell when it is used.
1504 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
1505 When not configured the default commit message editor is used instead.
1507 showBranch.default::
1508 The default set of branches for linkgit:git-show-branch[1].
1509 See linkgit:git-show-branch[1].
1511 splitIndex.maxPercentChange::
1512 When the split index feature is used, this specifies the
1513 percent of entries the split index can contain compared to the
1514 total number of entries in both the split index and the shared
1515 index before a new shared index is written.
1516 The value should be between 0 and 100. If the value is 0 then
1517 a new shared index is always written, if it is 100 a new
1518 shared index is never written.
1519 By default the value is 20, so a new shared index is written
1520 if the number of entries in the split index would be greater
1521 than 20 percent of the total number of entries.
1522 See linkgit:git-update-index[1].
1524 splitIndex.sharedIndexExpire::
1525 When the split index feature is used, shared index files that
1526 were not modified since the time this variable specifies will
1527 be removed when a new shared index file is created. The value
1528 "now" expires all entries immediately, and "never" suppresses
1529 expiration altogether.
1530 The default value is "2.weeks.ago".
1531 Note that a shared index file is considered modified (for the
1532 purpose of expiration) each time a new split-index file is
1533 either created based on it or read from it.
1534 See linkgit:git-update-index[1].
1536 status.relativePaths::
1537 By default, linkgit:git-status[1] shows paths relative to the
1538 current directory. Setting this variable to `false` shows paths
1539 relative to the repository root (this was the default for Git
1543 Set to true to enable --short by default in linkgit:git-status[1].
1544 The option --no-short takes precedence over this variable.
1547 Set to true to enable --branch by default in linkgit:git-status[1].
1548 The option --no-branch takes precedence over this variable.
1550 status.displayCommentPrefix::
1551 If set to true, linkgit:git-status[1] will insert a comment
1552 prefix before each output line (starting with
1553 `core.commentChar`, i.e. `#` by default). This was the
1554 behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
1557 status.renameLimit::
1558 The number of files to consider when performing rename detection
1559 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
1560 the value of diff.renameLimit.
1563 Whether and how Git detects renames in linkgit:git-status[1] and
1564 linkgit:git-commit[1] . If set to "false", rename detection is
1565 disabled. If set to "true", basic rename detection is enabled.
1566 If set to "copies" or "copy", Git will detect copies, as well.
1567 Defaults to the value of diff.renames.
1570 If set to true, linkgit:git-status[1] will display the number of
1571 entries currently stashed away.
1574 status.showUntrackedFiles::
1575 By default, linkgit:git-status[1] and linkgit:git-commit[1] show
1576 files which are not currently tracked by Git. Directories which
1577 contain only untracked files, are shown with the directory name
1578 only. Showing untracked files means that Git needs to lstat() all
1579 the files in the whole repository, which might be slow on some
1580 systems. So, this variable controls how the commands displays
1581 the untracked files. Possible values are:
1584 * `no` - Show no untracked files.
1585 * `normal` - Show untracked files and directories.
1586 * `all` - Show also individual files in untracked directories.
1589 If this variable is not specified, it defaults to 'normal'.
1590 This variable can be overridden with the -u|--untracked-files option
1591 of linkgit:git-status[1] and linkgit:git-commit[1].
1593 status.submoduleSummary::
1595 If this is set to a non zero number or true (identical to -1 or an
1596 unlimited number), the submodule summary will be enabled and a
1597 summary of commits for modified submodules will be shown (see
1598 --summary-limit option of linkgit:git-submodule[1]). Please note
1599 that the summary output command will be suppressed for all
1600 submodules when `diff.ignoreSubmodules` is set to 'all' or only
1601 for those submodules where `submodule.<name>.ignore=all`. The only
1602 exception to that rule is that status and commit will show staged
1603 submodule changes. To
1604 also view the summary for ignored submodules you can either use
1605 the --ignore-submodules=dirty command-line option or the 'git
1606 submodule summary' command, which shows a similar output but does
1607 not honor these settings.
1610 If this is set to true, the `git stash show` command without an
1611 option will show the stash entry in patch form. Defaults to false.
1612 See description of 'show' command in linkgit:git-stash[1].
1615 If this is set to true, the `git stash show` command without an
1616 option will show diffstat of the stash entry. Defaults to true.
1617 See description of 'show' command in linkgit:git-stash[1].
1619 include::submodule-config.txt[]
1621 tag.forceSignAnnotated::
1622 A boolean to specify whether annotated tags created should be GPG signed.
1623 If `--annotate` is specified on the command line, it takes
1624 precedence over this option.
1627 This variable controls the sort ordering of tags when displayed by
1628 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
1629 value of this variable will be used as the default.
1632 This variable can be used to restrict the permission bits of
1633 tar archive entries. The default is 0002, which turns off the
1634 world write bit. The special value "user" indicates that the
1635 archiving user's umask will be used instead. See umask(2) and
1636 linkgit:git-archive[1].
1638 transfer.fsckObjects::
1639 When `fetch.fsckObjects` or `receive.fsckObjects` are
1640 not set, the value of this variable is used instead.
1643 When set, the fetch or receive will abort in the case of a malformed
1644 object or a link to a nonexistent object. In addition, various other
1645 issues are checked for, including legacy issues (see `fsck.<msg-id>`),
1646 and potential security issues like the existence of a `.GIT` directory
1647 or a malicious `.gitmodules` file (see the release notes for v2.2.1
1648 and v2.17.1 for details). Other sanity and security checks may be
1649 added in future releases.
1651 On the receiving side, failing fsckObjects will make those objects
1652 unreachable, see "QUARANTINE ENVIRONMENT" in
1653 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
1654 instead be left unreferenced in the repository.
1656 Due to the non-quarantine nature of the `fetch.fsckObjects`
1657 implementation it can not be relied upon to leave the object store
1658 clean like `receive.fsckObjects` can.
1660 As objects are unpacked they're written to the object store, so there
1661 can be cases where malicious objects get introduced even though the
1662 "fetch" failed, only to have a subsequent "fetch" succeed because only
1663 new incoming objects are checked, not those that have already been
1664 written to the object store. That difference in behavior should not be
1665 relied upon. In the future, such objects may be quarantined for
1668 For now, the paranoid need to find some way to emulate the quarantine
1669 environment if they'd like the same protection as "push". E.g. in the
1670 case of an internal mirror do the mirroring in two steps, one to fetch
1671 the untrusted objects, and then do a second "push" (which will use the
1672 quarantine) to another internal repo, and have internal clients
1673 consume this pushed-to repository, or embargo internal fetches and
1674 only allow them once a full "fsck" has run (and no new fetches have
1675 happened in the meantime).
1678 String(s) `receive-pack` and `upload-pack` use to decide which
1679 refs to omit from their initial advertisements. Use more than
1680 one definition to specify multiple prefix strings. A ref that is
1681 under the hierarchies listed in the value of this variable is
1682 excluded, and is hidden when responding to `git push` or `git
1683 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
1684 program-specific versions of this config.
1686 You may also include a `!` in front of the ref name to negate the entry,
1687 explicitly exposing it, even if an earlier entry marked it as hidden.
1688 If you have multiple hideRefs values, later entries override earlier ones
1689 (and entries in more-specific config files override less-specific ones).
1691 If a namespace is in use, the namespace prefix is stripped from each
1692 reference before it is matched against `transfer.hiderefs` patterns.
1693 For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
1694 the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
1695 is omitted from the advertisements but `refs/heads/master` and
1696 `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
1697 "have" lines. In order to match refs before stripping, add a `^` in front of
1698 the ref name. If you combine `!` and `^`, `!` must be specified first.
1700 Even if you hide refs, a client may still be able to steal the target
1701 objects via the techniques described in the "SECURITY" section of the
1702 linkgit:gitnamespaces[7] man page; it's best to keep private data in a
1703 separate repository.
1705 transfer.unpackLimit::
1706 When `fetch.unpackLimit` or `receive.unpackLimit` are
1707 not set, the value of this variable is used instead.
1708 The default value is 100.
1710 uploadarchive.allowUnreachable::
1711 If true, allow clients to use `git archive --remote` to request
1712 any tree, whether reachable from the ref tips or not. See the
1713 discussion in the "SECURITY" section of
1714 linkgit:git-upload-archive[1] for more details. Defaults to
1717 uploadpack.hideRefs::
1718 This variable is the same as `transfer.hideRefs`, but applies
1719 only to `upload-pack` (and so affects only fetches, not pushes).
1720 An attempt to fetch a hidden ref by `git fetch` will fail. See
1721 also `uploadpack.allowTipSHA1InWant`.
1723 uploadpack.allowTipSHA1InWant::
1724 When `uploadpack.hideRefs` is in effect, allow `upload-pack`
1725 to accept a fetch request that asks for an object at the tip
1726 of a hidden ref (by default, such a request is rejected).
1727 See also `uploadpack.hideRefs`. Even if this is false, a client
1728 may be able to steal objects via the techniques described in the
1729 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
1730 best to keep private data in a separate repository.
1732 uploadpack.allowReachableSHA1InWant::
1733 Allow `upload-pack` to accept a fetch request that asks for an
1734 object that is reachable from any ref tip. However, note that
1735 calculating object reachability is computationally expensive.
1736 Defaults to `false`. Even if this is false, a client may be able
1737 to steal objects via the techniques described in the "SECURITY"
1738 section of the linkgit:gitnamespaces[7] man page; it's best to
1739 keep private data in a separate repository.
1741 uploadpack.allowAnySHA1InWant::
1742 Allow `upload-pack` to accept a fetch request that asks for any
1744 Defaults to `false`.
1746 uploadpack.keepAlive::
1747 When `upload-pack` has started `pack-objects`, there may be a
1748 quiet period while `pack-objects` prepares the pack. Normally
1749 it would output progress information, but if `--quiet` was used
1750 for the fetch, `pack-objects` will output nothing at all until
1751 the pack data begins. Some clients and networks may consider
1752 the server to be hung and give up. Setting this option instructs
1753 `upload-pack` to send an empty keepalive packet every
1754 `uploadpack.keepAlive` seconds. Setting this option to 0
1755 disables keepalive packets entirely. The default is 5 seconds.
1757 uploadpack.packObjectsHook::
1758 If this option is set, when `upload-pack` would run
1759 `git pack-objects` to create a packfile for a client, it will
1760 run this shell command instead. The `pack-objects` command and
1761 arguments it _would_ have run (including the `git pack-objects`
1762 at the beginning) are appended to the shell command. The stdin
1763 and stdout of the hook are treated as if `pack-objects` itself
1764 was run. I.e., `upload-pack` will feed input intended for
1765 `pack-objects` to the hook, and expects a completed packfile on
1768 Note that this configuration variable is ignored if it is seen in the
1769 repository-level config (this is a safety measure against fetching from
1770 untrusted repositories).
1772 uploadpack.allowFilter::
1773 If this option is set, `upload-pack` will support partial
1774 clone and partial fetch object filtering.
1776 uploadpack.allowRefInWant::
1777 If this option is set, `upload-pack` will support the `ref-in-want`
1778 feature of the protocol version 2 `fetch` command. This feature
1779 is intended for the benefit of load-balanced servers which may
1780 not have the same view of what OIDs their refs point to due to
1783 url.<base>.insteadOf::
1784 Any URL that starts with this value will be rewritten to
1785 start, instead, with <base>. In cases where some site serves a
1786 large number of repositories, and serves them with multiple
1787 access methods, and some users need to use different access
1788 methods, this feature allows people to specify any of the
1789 equivalent URLs and have Git automatically rewrite the URL to
1790 the best alternative for the particular user, even for a
1791 never-before-seen repository on the site. When more than one
1792 insteadOf strings match a given URL, the longest match is used.
1794 Note that any protocol restrictions will be applied to the rewritten
1795 URL. If the rewrite changes the URL to use a custom protocol or remote
1796 helper, you may need to adjust the `protocol.*.allow` config to permit
1797 the request. In particular, protocols you expect to use for submodules
1798 must be set to `always` rather than the default of `user`. See the
1799 description of `protocol.allow` above.
1801 url.<base>.pushInsteadOf::
1802 Any URL that starts with this value will not be pushed to;
1803 instead, it will be rewritten to start with <base>, and the
1804 resulting URL will be pushed to. In cases where some site serves
1805 a large number of repositories, and serves them with multiple
1806 access methods, some of which do not allow push, this feature
1807 allows people to specify a pull-only URL and have Git
1808 automatically use an appropriate URL to push, even for a
1809 never-before-seen repository on the site. When more than one
1810 pushInsteadOf strings match a given URL, the longest match is
1811 used. If a remote has an explicit pushurl, Git will ignore this
1812 setting for that remote.
1815 Your email address to be recorded in any newly created commits.
1816 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
1817 `EMAIL` environment variables. See linkgit:git-commit-tree[1].
1820 Your full name to be recorded in any newly created commits.
1821 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
1822 environment variables. See linkgit:git-commit-tree[1].
1824 user.useConfigOnly::
1825 Instruct Git to avoid trying to guess defaults for `user.email`
1826 and `user.name`, and instead retrieve the values only from the
1827 configuration. For example, if you have multiple email addresses
1828 and would like to use a different one for each repository, then
1829 with this configuration option set to `true` in the global config
1830 along with a name, Git will prompt you to set up an email before
1831 making new commits in a newly cloned repository.
1832 Defaults to `false`.
1835 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
1836 key you want it to automatically when creating a signed tag or
1837 commit, you can override the default selection with this variable.
1838 This option is passed unchanged to gpg's --local-user parameter,
1839 so you may specify a key using any method that gpg supports.
1841 versionsort.prereleaseSuffix (deprecated)::
1842 Deprecated alias for `versionsort.suffix`. Ignored if
1843 `versionsort.suffix` is set.
1845 versionsort.suffix::
1846 Even when version sort is used in linkgit:git-tag[1], tagnames
1847 with the same base version but different suffixes are still sorted
1848 lexicographically, resulting e.g. in prerelease tags appearing
1849 after the main release (e.g. "1.0-rc1" after "1.0"). This
1850 variable can be specified to determine the sorting order of tags
1851 with different suffixes.
1853 By specifying a single suffix in this variable, any tagname containing
1854 that suffix will appear before the corresponding main release. E.g. if
1855 the variable is set to "-rc", then all "1.0-rcX" tags will appear before
1856 "1.0". If specified multiple times, once per suffix, then the order of
1857 suffixes in the configuration will determine the sorting order of tagnames
1858 with those suffixes. E.g. if "-pre" appears before "-rc" in the
1859 configuration, then all "1.0-preX" tags will be listed before any
1860 "1.0-rcX" tags. The placement of the main release tag relative to tags
1861 with various suffixes can be determined by specifying the empty suffix
1862 among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
1863 "-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
1864 are listed first, followed by "v4.8", then "v4.8-ckX" and finally
1867 If more than one suffixes match the same tagname, then that tagname will
1868 be sorted according to the suffix which starts at the earliest position in
1869 the tagname. If more than one different matching suffixes start at
1870 that earliest position, then that tagname will be sorted according to the
1871 longest of those suffixes.
1872 The sorting order between different suffixes is undefined if they are
1873 in multiple config files.
1876 Specify a web browser that may be used by some commands.
1877 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
1880 worktree.guessRemote::
1881 With `add`, if no branch argument, and neither of `-b` nor
1882 `-B` nor `--detach` are given, the command defaults to
1883 creating a new branch from HEAD. If `worktree.guessRemote` is
1884 set to true, `worktree add` tries to find a remote-tracking
1885 branch whose name uniquely matches the new branch name. If
1886 such a branch exists, it is checked out and set as "upstream"
1887 for the new branch. If no such match can be found, it falls
1888 back to creating a new branch from the current HEAD.