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[]
336 include::config/gc.txt[]
338 include::config/gitcvs.txt[]
340 include::config/gitweb.txt[]
342 include::config/grep.txt[]
344 include::config/gpg.txt[]
346 include::config/gui.txt[]
348 include::config/guitool.txt[]
350 include::config/help.txt[]
353 Override the HTTP proxy, normally configured using the 'http_proxy',
354 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
355 addition to the syntax understood by curl, it is possible to specify a
356 proxy string with a user name but no password, in which case git will
357 attempt to acquire one in the same way it does for other credentials. See
358 linkgit:gitcredentials[7] for more information. The syntax thus is
359 '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
360 on a per-remote basis; see remote.<name>.proxy
362 http.proxyAuthMethod::
363 Set the method with which to authenticate against the HTTP proxy. This
364 only takes effect if the configured proxy string contains a user name part
365 (i.e. is of the form 'user@host' or 'user@host:port'). This can be
366 overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
367 Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
368 variable. Possible values are:
371 * `anyauth` - Automatically pick a suitable authentication method. It is
372 assumed that the proxy answers an unauthenticated request with a 407
373 status code and one or more Proxy-authenticate headers with supported
374 authentication methods. This is the default.
375 * `basic` - HTTP Basic authentication
376 * `digest` - HTTP Digest authentication; this prevents the password from being
377 transmitted to the proxy in clear text
378 * `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
380 * `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
384 Attempt authentication without seeking a username or password. This
385 can be used to attempt GSS-Negotiate authentication without specifying
386 a username in the URL, as libcurl normally requires a username for
390 Control GSSAPI credential delegation. The delegation is disabled
391 by default in libcurl since version 7.21.7. Set parameter to tell
392 the server what it is allowed to delegate when it comes to user
393 credentials. Used with GSS/kerberos. Possible values are:
396 * `none` - Don't allow any delegation.
397 * `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
398 Kerberos service ticket, which is a matter of realm policy.
399 * `always` - Unconditionally allow the server to delegate.
404 Pass an additional HTTP header when communicating with a server. If
405 more than one such entry exists, all of them are added as extra
406 headers. To allow overriding the settings inherited from the system
407 config, an empty value will reset the extra headers to the empty list.
410 The pathname of a file containing previously stored cookie lines,
412 in the Git http session, if they match the server. The file format
413 of the file to read cookies from should be plain HTTP headers or
414 the Netscape/Mozilla cookie file format (see `curl(1)`).
415 NOTE that the file specified with http.cookieFile is used only as
416 input unless http.saveCookies is set.
419 If set, store cookies received during requests to the file specified by
420 http.cookieFile. Has no effect if http.cookieFile is unset.
423 The SSL version to use when negotiating an SSL connection, if you
424 want to force the default. The available and default version
425 depend on whether libcurl was built against NSS or OpenSSL and the
426 particular configuration of the crypto library in use. Internally
427 this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
428 documentation for more details on the format of this option and
429 for the ssl version supported. Actually the possible values of
441 Can be overridden by the `GIT_SSL_VERSION` environment variable.
442 To force git to use libcurl's default ssl version and ignore any
443 explicit http.sslversion option, set `GIT_SSL_VERSION` to the
447 A list of SSL ciphers to use when negotiating an SSL connection.
448 The available ciphers depend on whether libcurl was built against
449 NSS or OpenSSL and the particular configuration of the crypto
450 library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
451 option; see the libcurl documentation for more details on the format
454 Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
455 To force git to use libcurl's default cipher list and ignore any
456 explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
460 Whether to verify the SSL certificate when fetching or pushing
461 over HTTPS. Defaults to true. Can be overridden by the
462 `GIT_SSL_NO_VERIFY` environment variable.
465 File containing the SSL certificate when fetching or pushing
466 over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
470 File containing the SSL private key when fetching or pushing
471 over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
474 http.sslCertPasswordProtected::
475 Enable Git's password prompt for the SSL certificate. Otherwise
476 OpenSSL will prompt the user, possibly many times, if the
477 certificate or private key is encrypted. Can be overridden by the
478 `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
481 File containing the certificates to verify the peer with when
482 fetching or pushing over HTTPS. Can be overridden by the
483 `GIT_SSL_CAINFO` environment variable.
486 Path containing files with the CA certificates to verify the peer
487 with when fetching or pushing over HTTPS. Can be overridden
488 by the `GIT_SSL_CAPATH` environment variable.
491 Name of the SSL backend to use (e.g. "openssl" or "schannel").
492 This option is ignored if cURL lacks support for choosing the SSL
495 http.schannelCheckRevoke::
496 Used to enforce or disable certificate revocation checks in cURL
497 when http.sslBackend is set to "schannel". Defaults to `true` if
498 unset. Only necessary to disable this if Git consistently errors
499 and the message is about checking the revocation status of a
500 certificate. This option is ignored if cURL lacks support for
501 setting the relevant SSL option at runtime.
503 http.schannelUseSSLCAInfo::
504 As of cURL v7.60.0, the Secure Channel backend can use the
505 certificate bundle provided via `http.sslCAInfo`, but that would
506 override the Windows Certificate Store. Since this is not desirable
507 by default, Git will tell cURL not to use that bundle by default
508 when the `schannel` backend was configured via `http.sslBackend`,
509 unless `http.schannelUseSSLCAInfo` overrides this behavior.
512 Public key of the https service. It may either be the filename of
513 a PEM or DER encoded public key file or a string starting with
514 'sha256//' followed by the base64 encoded sha256 hash of the
515 public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
516 exit with an error if this option is set but not supported by
520 Attempt to use AUTH SSL/TLS and encrypted data transfers
521 when connecting via regular FTP protocol. This might be needed
522 if the FTP server requires it for security reasons or you wish
523 to connect securely whenever remote FTP server supports it.
524 Default is false since it might trigger certificate verification
525 errors on misconfigured servers.
528 How many HTTP requests to launch in parallel. Can be overridden
529 by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
532 The number of curl sessions (counted across slots) to be kept across
533 requests. They will not be ended with curl_easy_cleanup() until
534 http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
535 value will be capped at 1. Defaults to 1.
538 Maximum size in bytes of the buffer used by smart HTTP
539 transports when POSTing data to the remote system.
540 For requests larger than this buffer size, HTTP/1.1 and
541 Transfer-Encoding: chunked is used to avoid creating a
542 massive pack file locally. Default is 1 MiB, which is
543 sufficient for most requests.
545 http.lowSpeedLimit, http.lowSpeedTime::
546 If the HTTP transfer speed is less than 'http.lowSpeedLimit'
547 for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
548 Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
549 `GIT_HTTP_LOW_SPEED_TIME` environment variables.
552 A boolean which disables using of EPSV ftp command by curl.
553 This can helpful with some "poor" ftp servers which don't
554 support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV`
555 environment variable. Default is false (curl will use EPSV).
558 The HTTP USER_AGENT string presented to an HTTP server. The default
559 value represents the version of the client Git such as git/1.7.1.
560 This option allows you to override this value to a more common value
561 such as Mozilla/4.0. This may be necessary, for instance, if
562 connecting through a firewall that restricts HTTP connections to a set
563 of common USER_AGENT strings (but not including those like git/1.7.1).
564 Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.
566 http.followRedirects::
567 Whether git should follow HTTP redirects. If set to `true`, git
568 will transparently follow any redirect issued by a server it
569 encounters. If set to `false`, git will treat all redirects as
570 errors. If set to `initial`, git will follow redirects only for
571 the initial request to a remote, but not for subsequent
572 follow-up HTTP requests. Since git uses the redirected URL as
573 the base for the follow-up requests, this is generally
574 sufficient. The default is `initial`.
577 Any of the http.* options above can be applied selectively to some URLs.
578 For a config key to match a URL, each element of the config key is
579 compared to that of the URL, in the following order:
582 . Scheme (e.g., `https` in `https://example.com/`). This field
583 must match exactly between the config key and the URL.
585 . Host/domain name (e.g., `example.com` in `https://example.com/`).
586 This field must match between the config key and the URL. It is
587 possible to specify a `*` as part of the host name to match all subdomains
588 at this level. `https://*.example.com/` for example would match
589 `https://foo.example.com/`, but not `https://foo.bar.example.com/`.
591 . Port number (e.g., `8080` in `http://example.com:8080/`).
592 This field must match exactly between the config key and the URL.
593 Omitted port numbers are automatically converted to the correct
594 default for the scheme before matching.
596 . Path (e.g., `repo.git` in `https://example.com/repo.git`). The
597 path field of the config key must match the path field of the URL
598 either exactly or as a prefix of slash-delimited path elements. This means
599 a config key with path `foo/` matches URL path `foo/bar`. A prefix can only
600 match on a slash (`/`) boundary. Longer matches take precedence (so a config
601 key with path `foo/bar` is a better match to URL path `foo/bar` than a config
602 key with just path `foo/`).
604 . User name (e.g., `user` in `https://user@example.com/repo.git`). If
605 the config key has a user name it must match the user name in the
606 URL exactly. If the config key does not have a user name, that
607 config key will match a URL with any user name (including none),
608 but at a lower precedence than a config key with a user name.
611 The list above is ordered by decreasing precedence; a URL that matches
612 a config key's path is preferred to one that matches its user name. For example,
613 if the URL is `https://user@example.com/foo/bar` a config key match of
614 `https://example.com/foo` will be preferred over a config key match of
615 `https://user@example.com`.
617 All URLs are normalized before attempting any matching (the password part,
618 if embedded in the URL, is always ignored for matching purposes) so that
619 equivalent URLs that are simply spelled differently will match properly.
620 Environment variable settings always override any matches. The URLs that are
621 matched against are those given directly to Git commands. This means any URLs
622 visited as a result of a redirection do not participate in matching.
624 i18n.commitEncoding::
625 Character encoding the commit messages are stored in; Git itself
626 does not care per se, but this information is necessary e.g. when
627 importing commits from emails or in the gitk graphical history
628 browser (and possibly at other places in the future or in other
629 porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
631 i18n.logOutputEncoding::
632 Character encoding the commit messages are converted to when
633 running 'git log' and friends.
636 The configuration variables in the 'imap' section are described
637 in linkgit:git-imap-send[1].
640 Specifies the number of threads to spawn when loading the index.
641 This is meant to reduce index load time on multiprocessor machines.
642 Specifying 0 or 'true' will cause Git to auto-detect the number of
643 CPU's and set the number of threads accordingly. Specifying 1 or
644 'false' will disable multithreading. Defaults to 'true'.
647 Specify the version with which new index files should be
648 initialized. This does not affect existing repositories.
651 Specify the directory from which templates will be copied.
652 (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
655 Specify the program that will be used to browse your working
656 repository in gitweb. See linkgit:git-instaweb[1].
659 The HTTP daemon command-line to start gitweb on your working
660 repository. See linkgit:git-instaweb[1].
663 If true the web server started by linkgit:git-instaweb[1] will
664 be bound to the local IP (127.0.0.1).
666 instaweb.modulePath::
667 The default module path for linkgit:git-instaweb[1] to use
668 instead of /usr/lib/apache2/modules. Only used if httpd
672 The port number to bind the gitweb httpd to. See
673 linkgit:git-instaweb[1].
675 interactive.singleKey::
676 In interactive commands, allow the user to provide one-letter
677 input with a single key (i.e., without hitting enter).
678 Currently this is used by the `--patch` mode of
679 linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
680 linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
681 setting is silently ignored if portable keystroke input
682 is not available; requires the Perl module Term::ReadKey.
684 interactive.diffFilter::
685 When an interactive command (such as `git add --patch`) shows
686 a colorized diff, git will pipe the diff through the shell
687 command defined by this configuration variable. The command may
688 mark up the diff further for human consumption, provided that it
689 retains a one-to-one correspondence with the lines in the
690 original diff. Defaults to disabled (no filtering).
693 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
694 linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
695 override this option with `--no-abbrev-commit`.
698 Set the default date-time mode for the 'log' command.
699 Setting a value for log.date is similar to using 'git log''s
700 `--date` option. See linkgit:git-log[1] for details.
703 Print out the ref names of any commits that are shown by the log
704 command. If 'short' is specified, the ref name prefixes 'refs/heads/',
705 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
706 specified, the full ref name (including prefix) will be printed.
707 If 'auto' is specified, then if the output is going to a terminal,
708 the ref names are shown as if 'short' were given, otherwise no ref
709 names are shown. This is the same as the `--decorate` option
713 If `true`, `git log` will act as if the `--follow` option was used when
714 a single <path> is given. This has the same limitations as `--follow`,
715 i.e. it cannot be used to follow multiple files and does not work well
716 on non-linear history.
719 A list of colors, separated by commas, that can be used to draw
720 history lines in `git log --graph`.
723 If true, the initial commit will be shown as a big creation event.
724 This is equivalent to a diff against an empty tree.
725 Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
726 normally hide the root commit will now show it. True by default.
729 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
730 linkgit:git-whatchanged[1] assume `--show-signature`.
733 If true, makes linkgit:git-log[1], linkgit:git-show[1], and
734 linkgit:git-whatchanged[1] assume `--use-mailmap`.
737 If true, makes linkgit:git-mailinfo[1] (and therefore
738 linkgit:git-am[1]) act by default as if the --scissors option
739 was provided on the command-line. When active, this features
740 removes everything from the message body before a scissors
741 line (i.e. consisting mainly of ">8", "8<" and "-").
744 The location of an augmenting mailmap file. The default
745 mailmap, located in the root of the repository, is loaded
746 first, then the mailmap file pointed to by this variable.
747 The location of the mailmap file may be in a repository
748 subdirectory, or somewhere outside of the repository itself.
749 See linkgit:git-shortlog[1] and linkgit:git-blame[1].
752 Like `mailmap.file`, but consider the value as a reference to a
753 blob in the repository. If both `mailmap.file` and
754 `mailmap.blob` are given, both are parsed, with entries from
755 `mailmap.file` taking precedence. In a bare repository, this
756 defaults to `HEAD:.mailmap`. In a non-bare repository, it
760 Specify the programs that may be used to display help in the
761 'man' format. See linkgit:git-help[1].
764 Specify the command to invoke the specified man viewer. The
765 specified command is evaluated in shell with the man page
766 passed as argument. (See linkgit:git-help[1].)
769 Override the path for the given tool that may be used to
770 display help in the 'man' format. See linkgit:git-help[1].
772 include::merge-config.txt[]
774 mergetool.<tool>.path::
775 Override the path for the given tool. This is useful in case
776 your tool is not in the PATH.
778 mergetool.<tool>.cmd::
779 Specify the command to invoke the specified merge tool. The
780 specified command is evaluated in shell with the following
781 variables available: 'BASE' is the name of a temporary file
782 containing the common base of the files to be merged, if available;
783 'LOCAL' is the name of a temporary file containing the contents of
784 the file on the current branch; 'REMOTE' is the name of a temporary
785 file containing the contents of the file from the branch being
786 merged; 'MERGED' contains the name of the file to which the merge
787 tool should write the results of a successful merge.
789 mergetool.<tool>.trustExitCode::
790 For a custom merge command, specify whether the exit code of
791 the merge command can be used to determine whether the merge was
792 successful. If this is not set to true then the merge target file
793 timestamp is checked and the merge assumed to have been successful
794 if the file has been updated, otherwise the user is prompted to
795 indicate the success of the merge.
797 mergetool.meld.hasOutput::
798 Older versions of `meld` do not support the `--output` option.
799 Git will attempt to detect whether `meld` supports `--output`
800 by inspecting the output of `meld --help`. Configuring
801 `mergetool.meld.hasOutput` will make Git skip these checks and
802 use the configured value instead. Setting `mergetool.meld.hasOutput`
803 to `true` tells Git to unconditionally use the `--output` option,
804 and `false` avoids using `--output`.
806 mergetool.keepBackup::
807 After performing a merge, the original file with conflict markers
808 can be saved as a file with a `.orig` extension. If this variable
809 is set to `false` then this file is not preserved. Defaults to
810 `true` (i.e. keep the backup files).
812 mergetool.keepTemporaries::
813 When invoking a custom merge tool, Git uses a set of temporary
814 files to pass to the tool. If the tool returns an error and this
815 variable is set to `true`, then these temporary files will be
816 preserved, otherwise they will be removed after the tool has
817 exited. Defaults to `false`.
819 mergetool.writeToTemp::
820 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
821 conflicting files in the worktree by default. Git will attempt
822 to use a temporary directory for these files when set `true`.
826 Prompt before each invocation of the merge resolution program.
828 notes.mergeStrategy::
829 Which merge strategy to choose by default when resolving notes
830 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
831 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
832 section of linkgit:git-notes[1] for more information on each strategy.
834 notes.<name>.mergeStrategy::
835 Which merge strategy to choose when doing a notes merge into
836 refs/notes/<name>. This overrides the more general
837 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
838 linkgit:git-notes[1] for more information on the available strategies.
841 The (fully qualified) refname from which to show notes when
842 showing commit messages. The value of this variable can be set
843 to a glob, in which case notes from all matching refs will be
844 shown. You may also specify this configuration variable
845 several times. A warning will be issued for refs that do not
846 exist, but a glob that does not match any refs is silently
849 This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
850 environment variable, which must be a colon separated list of refs or
853 The effective value of "core.notesRef" (possibly overridden by
854 GIT_NOTES_REF) is also implicitly added to the list of refs to be
857 notes.rewrite.<command>::
858 When rewriting commits with <command> (currently `amend` or
859 `rebase`) and this variable is set to `true`, Git
860 automatically copies your notes from the original to the
861 rewritten commit. Defaults to `true`, but see
862 "notes.rewriteRef" below.
865 When copying notes during a rewrite (see the
866 "notes.rewrite.<command>" option), determines what to do if
867 the target commit already has a note. Must be one of
868 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
869 Defaults to `concatenate`.
871 This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
872 environment variable.
875 When copying notes during a rewrite, specifies the (fully
876 qualified) ref whose notes should be copied. The ref may be a
877 glob, in which case notes in all matching refs will be copied.
878 You may also specify this configuration several times.
880 Does not have a default value; you must configure this variable to
881 enable note rewriting. Set it to `refs/notes/commits` to enable
882 rewriting for the default commit notes.
884 This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
885 environment variable, which must be a colon separated list of refs or
889 The size of the window used by linkgit:git-pack-objects[1] when no
890 window size is given on the command line. Defaults to 10.
893 The maximum delta depth used by linkgit:git-pack-objects[1] when no
894 maximum depth is given on the command line. Defaults to 50.
895 Maximum value is 4095.
898 The maximum size of memory that is consumed by each thread
899 in linkgit:git-pack-objects[1] for pack window memory when
900 no limit is given on the command line. The value can be
901 suffixed with "k", "m", or "g". When left unconfigured (or
902 set explicitly to 0), there will be no limit.
905 An integer -1..9, indicating the compression level for objects
906 in a pack file. -1 is the zlib default. 0 means no
907 compression, and 1..9 are various speed/size tradeoffs, 9 being
908 slowest. If not set, defaults to core.compression. If that is
909 not set, defaults to -1, the zlib default, which is "a default
910 compromise between speed and compression (currently equivalent
913 Note that changing the compression level will not automatically recompress
914 all existing objects. You can force recompression by passing the -F option
915 to linkgit:git-repack[1].
918 An extended regular expression configuring a set of delta
919 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
923 Specify an island name which gets to have its objects be
924 packed first. This creates a kind of pseudo-pack at the front
925 of one pack, so that the objects from the specified island are
926 hopefully faster to copy into any pack that should be served
927 to a user requesting these objects. In practice this means
928 that the island specified should likely correspond to what is
929 the most commonly cloned in the repo. See also "DELTA ISLANDS"
930 in linkgit:git-pack-objects[1].
932 pack.deltaCacheSize::
933 The maximum memory in bytes used for caching deltas in
934 linkgit:git-pack-objects[1] before writing them out to a pack.
935 This cache is used to speed up the writing object phase by not
936 having to recompute the final delta result once the best match
937 for all objects is found. Repacking large repositories on machines
938 which are tight with memory might be badly impacted by this though,
939 especially if this cache pushes the system into swapping.
940 A value of 0 means no limit. The smallest size of 1 byte may be
941 used to virtually disable this cache. Defaults to 256 MiB.
943 pack.deltaCacheLimit::
944 The maximum size of a delta, that is cached in
945 linkgit:git-pack-objects[1]. This cache is used to speed up the
946 writing object phase by not having to recompute the final delta
947 result once the best match for all objects is found.
948 Defaults to 1000. Maximum value is 65535.
951 Specifies the number of threads to spawn when searching for best
952 delta matches. This requires that linkgit:git-pack-objects[1]
953 be compiled with pthreads otherwise this option is ignored with a
954 warning. This is meant to reduce packing time on multiprocessor
955 machines. The required amount of memory for the delta search window
956 is however multiplied by the number of threads.
957 Specifying 0 will cause Git to auto-detect the number of CPU's
958 and set the number of threads accordingly.
961 Specify the default pack index version. Valid values are 1 for
962 legacy pack index used by Git versions prior to 1.5.2, and 2 for
963 the new pack index with capabilities for packs larger than 4 GB
964 as well as proper protection against the repacking of corrupted
965 packs. Version 2 is the default. Note that version 2 is enforced
966 and this config option ignored whenever the corresponding pack is
969 If you have an old Git that does not understand the version 2 `*.idx` file,
970 cloning or fetching over a non native protocol (e.g. "http")
971 that will copy both `*.pack` file and corresponding `*.idx` file from the
972 other side may give you a repository that cannot be accessed with your
973 older version of Git. If the `*.pack` file is smaller than 2 GB, however,
974 you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
978 The maximum size of a pack. This setting only affects
979 packing to a file when repacking, i.e. the git:// protocol
980 is unaffected. It can be overridden by the `--max-pack-size`
981 option of linkgit:git-repack[1]. Reaching this limit results
982 in the creation of multiple packfiles; which in turn prevents
983 bitmaps from being created.
984 The minimum size allowed is limited to 1 MiB.
985 The default is unlimited.
986 Common unit suffixes of 'k', 'm', or 'g' are
990 When true, git will use pack bitmaps (if available) when packing
991 to stdout (e.g., during the server side of a fetch). Defaults to
992 true. You should not generally need to turn this off unless
993 you are debugging pack bitmaps.
995 pack.writeBitmaps (deprecated)::
996 This is a deprecated synonym for `repack.writeBitmaps`.
998 pack.writeBitmapHashCache::
999 When true, git will include a "hash cache" section in the bitmap
1000 index (if one is written). This cache can be used to feed git's
1001 delta heuristics, potentially leading to better deltas between
1002 bitmapped and non-bitmapped objects (e.g., when serving a fetch
1003 between an older, bitmapped pack and objects that have been
1004 pushed since the last gc). The downside is that it consumes 4
1005 bytes per object of disk space, and that JGit's bitmap
1006 implementation does not understand it, causing it to complain if
1007 Git and JGit are used on the same repository. Defaults to false.
1010 If the value is boolean, turns on or off pagination of the
1011 output of a particular Git subcommand when writing to a tty.
1012 Otherwise, turns on pagination for the subcommand using the
1013 pager specified by the value of `pager.<cmd>`. If `--paginate`
1014 or `--no-pager` is specified on the command line, it takes
1015 precedence over this option. To disable pagination for all
1016 commands, set `core.pager` or `GIT_PAGER` to `cat`.
1019 Alias for a --pretty= format string, as specified in
1020 linkgit:git-log[1]. Any aliases defined here can be used just
1021 as the built-in pretty formats could. For example,
1022 running `git config pretty.changelog "format:* %H %s"`
1023 would cause the invocation `git log --pretty=changelog`
1024 to be equivalent to running `git log "--pretty=format:* %H %s"`.
1025 Note that an alias with the same name as a built-in format
1026 will be silently ignored.
1029 If set, provide a user defined default policy for all protocols which
1030 don't explicitly have a policy (`protocol.<name>.allow`). By default,
1031 if unset, known-safe protocols (http, https, git, ssh, file) have a
1032 default policy of `always`, known-dangerous protocols (ext) have a
1033 default policy of `never`, and all other protocols have a default
1034 policy of `user`. Supported policies:
1038 * `always` - protocol is always able to be used.
1040 * `never` - protocol is never able to be used.
1042 * `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
1043 either unset or has a value of 1. This policy should be used when you want a
1044 protocol to be directly usable by the user but don't want it used by commands which
1045 execute clone/fetch/push commands without user input, e.g. recursive
1046 submodule initialization.
1050 protocol.<name>.allow::
1051 Set a policy to be used by protocol `<name>` with clone/fetch/push
1052 commands. See `protocol.allow` above for the available policies.
1054 The protocol names currently used by git are:
1057 - `file`: any local file-based path (including `file://` URLs,
1060 - `git`: the anonymous git protocol over a direct TCP
1061 connection (or proxy, if configured)
1063 - `ssh`: git over ssh (including `host:path` syntax,
1066 - `http`: git over http, both "smart http" and "dumb http".
1067 Note that this does _not_ include `https`; if you want to configure
1068 both, you must do so individually.
1070 - any external helpers are named by their protocol (e.g., use
1071 `hg` to allow the `git-remote-hg` helper)
1075 Experimental. If set, clients will attempt to communicate with a
1076 server using the specified protocol version. If unset, no
1077 attempt will be made by the client to communicate using a
1078 particular protocol version, this results in protocol version 0
1084 * `0` - the original wire protocol.
1086 * `1` - the original wire protocol with the addition of a version string
1087 in the initial response from the server.
1089 * `2` - link:technical/protocol-v2.html[wire protocol version 2].
1093 include::pull-config.txt[]
1095 include::push-config.txt[]
1097 include::rebase-config.txt[]
1099 include::receive-config.txt[]
1101 remote.pushDefault::
1102 The remote to push to by default. Overrides
1103 `branch.<name>.remote` for all branches, and is overridden by
1104 `branch.<name>.pushRemote` for specific branches.
1107 The URL of a remote repository. See linkgit:git-fetch[1] or
1108 linkgit:git-push[1].
1110 remote.<name>.pushurl::
1111 The push URL of a remote repository. See linkgit:git-push[1].
1113 remote.<name>.proxy::
1114 For remotes that require curl (http, https and ftp), the URL to
1115 the proxy to use for that remote. Set to the empty string to
1116 disable proxying for that remote.
1118 remote.<name>.proxyAuthMethod::
1119 For remotes that require curl (http, https and ftp), the method to use for
1120 authenticating against the proxy in use (probably set in
1121 `remote.<name>.proxy`). See `http.proxyAuthMethod`.
1123 remote.<name>.fetch::
1124 The default set of "refspec" for linkgit:git-fetch[1]. See
1125 linkgit:git-fetch[1].
1127 remote.<name>.push::
1128 The default set of "refspec" for linkgit:git-push[1]. See
1129 linkgit:git-push[1].
1131 remote.<name>.mirror::
1132 If true, pushing to this remote will automatically behave
1133 as if the `--mirror` option was given on the command line.
1135 remote.<name>.skipDefaultUpdate::
1136 If true, this remote will be skipped by default when updating
1137 using linkgit:git-fetch[1] or the `update` subcommand of
1138 linkgit:git-remote[1].
1140 remote.<name>.skipFetchAll::
1141 If true, this remote will be skipped by default when updating
1142 using linkgit:git-fetch[1] or the `update` subcommand of
1143 linkgit:git-remote[1].
1145 remote.<name>.receivepack::
1146 The default program to execute on the remote side when pushing. See
1147 option --receive-pack of linkgit:git-push[1].
1149 remote.<name>.uploadpack::
1150 The default program to execute on the remote side when fetching. See
1151 option --upload-pack of linkgit:git-fetch-pack[1].
1153 remote.<name>.tagOpt::
1154 Setting this value to --no-tags disables automatic tag following when
1155 fetching from remote <name>. Setting it to --tags will fetch every
1156 tag from remote <name>, even if they are not reachable from remote
1157 branch heads. Passing these flags directly to linkgit:git-fetch[1] can
1158 override this setting. See options --tags and --no-tags of
1159 linkgit:git-fetch[1].
1162 Setting this to a value <vcs> will cause Git to interact with
1163 the remote with the git-remote-<vcs> helper.
1165 remote.<name>.prune::
1166 When set to true, fetching from this remote by default will also
1167 remove any remote-tracking references that no longer exist on the
1168 remote (as if the `--prune` option was given on the command line).
1169 Overrides `fetch.prune` settings, if any.
1171 remote.<name>.pruneTags::
1172 When set to true, fetching from this remote by default will also
1173 remove any local tags that no longer exist on the remote if pruning
1174 is activated in general via `remote.<name>.prune`, `fetch.prune` or
1175 `--prune`. Overrides `fetch.pruneTags` settings, if any.
1177 See also `remote.<name>.prune` and the PRUNING section of
1178 linkgit:git-fetch[1].
1181 The list of remotes which are fetched by "git remote update
1182 <group>". See linkgit:git-remote[1].
1184 repack.useDeltaBaseOffset::
1185 By default, linkgit:git-repack[1] creates packs that use
1186 delta-base offset. If you need to share your repository with
1187 Git older than version 1.4.4, either directly or via a dumb
1188 protocol such as http, then you need to set this option to
1189 "false" and repack. Access from old Git versions over the
1190 native protocol are unaffected by this option.
1192 repack.packKeptObjects::
1193 If set to true, makes `git repack` act as if
1194 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
1195 details. Defaults to `false` normally, but `true` if a bitmap
1196 index is being written (either via `--write-bitmap-index` or
1197 `repack.writeBitmaps`).
1199 repack.useDeltaIslands::
1200 If set to true, makes `git repack` act as if `--delta-islands`
1201 was passed. Defaults to `false`.
1203 repack.writeBitmaps::
1204 When true, git will write a bitmap index when packing all
1205 objects to disk (e.g., when `git repack -a` is run). This
1206 index can speed up the "counting objects" phase of subsequent
1207 packs created for clones and fetches, at the cost of some disk
1208 space and extra time spent on the initial repack. This has
1209 no effect if multiple packfiles are created.
1213 When set to true, `git-rerere` updates the index with the
1214 resulting contents after it cleanly resolves conflicts using
1215 previously recorded resolution. Defaults to false.
1218 Activate recording of resolved conflicts, so that identical
1219 conflict hunks can be resolved automatically, should they be
1220 encountered again. By default, linkgit:git-rerere[1] is
1221 enabled if there is an `rr-cache` directory under the
1222 `$GIT_DIR`, e.g. if "rerere" was previously used in the
1226 When set to true, 'git reset' will default to the '--quiet' option.
1228 include::sendemail-config.txt[]
1231 Text editor used by `git rebase -i` for editing the rebase instruction file.
1232 The value is meant to be interpreted by the shell when it is used.
1233 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
1234 When not configured the default commit message editor is used instead.
1236 showBranch.default::
1237 The default set of branches for linkgit:git-show-branch[1].
1238 See linkgit:git-show-branch[1].
1240 splitIndex.maxPercentChange::
1241 When the split index feature is used, this specifies the
1242 percent of entries the split index can contain compared to the
1243 total number of entries in both the split index and the shared
1244 index before a new shared index is written.
1245 The value should be between 0 and 100. If the value is 0 then
1246 a new shared index is always written, if it is 100 a new
1247 shared index is never written.
1248 By default the value is 20, so a new shared index is written
1249 if the number of entries in the split index would be greater
1250 than 20 percent of the total number of entries.
1251 See linkgit:git-update-index[1].
1253 splitIndex.sharedIndexExpire::
1254 When the split index feature is used, shared index files that
1255 were not modified since the time this variable specifies will
1256 be removed when a new shared index file is created. The value
1257 "now" expires all entries immediately, and "never" suppresses
1258 expiration altogether.
1259 The default value is "2.weeks.ago".
1260 Note that a shared index file is considered modified (for the
1261 purpose of expiration) each time a new split-index file is
1262 either created based on it or read from it.
1263 See linkgit:git-update-index[1].
1265 include::config/ssh.txt[]
1267 status.relativePaths::
1268 By default, linkgit:git-status[1] shows paths relative to the
1269 current directory. Setting this variable to `false` shows paths
1270 relative to the repository root (this was the default for Git
1274 Set to true to enable --short by default in linkgit:git-status[1].
1275 The option --no-short takes precedence over this variable.
1278 Set to true to enable --branch by default in linkgit:git-status[1].
1279 The option --no-branch takes precedence over this variable.
1281 status.displayCommentPrefix::
1282 If set to true, linkgit:git-status[1] will insert a comment
1283 prefix before each output line (starting with
1284 `core.commentChar`, i.e. `#` by default). This was the
1285 behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
1288 status.renameLimit::
1289 The number of files to consider when performing rename detection
1290 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
1291 the value of diff.renameLimit.
1294 Whether and how Git detects renames in linkgit:git-status[1] and
1295 linkgit:git-commit[1] . If set to "false", rename detection is
1296 disabled. If set to "true", basic rename detection is enabled.
1297 If set to "copies" or "copy", Git will detect copies, as well.
1298 Defaults to the value of diff.renames.
1301 If set to true, linkgit:git-status[1] will display the number of
1302 entries currently stashed away.
1305 status.showUntrackedFiles::
1306 By default, linkgit:git-status[1] and linkgit:git-commit[1] show
1307 files which are not currently tracked by Git. Directories which
1308 contain only untracked files, are shown with the directory name
1309 only. Showing untracked files means that Git needs to lstat() all
1310 the files in the whole repository, which might be slow on some
1311 systems. So, this variable controls how the commands displays
1312 the untracked files. Possible values are:
1315 * `no` - Show no untracked files.
1316 * `normal` - Show untracked files and directories.
1317 * `all` - Show also individual files in untracked directories.
1320 If this variable is not specified, it defaults to 'normal'.
1321 This variable can be overridden with the -u|--untracked-files option
1322 of linkgit:git-status[1] and linkgit:git-commit[1].
1324 status.submoduleSummary::
1326 If this is set to a non zero number or true (identical to -1 or an
1327 unlimited number), the submodule summary will be enabled and a
1328 summary of commits for modified submodules will be shown (see
1329 --summary-limit option of linkgit:git-submodule[1]). Please note
1330 that the summary output command will be suppressed for all
1331 submodules when `diff.ignoreSubmodules` is set to 'all' or only
1332 for those submodules where `submodule.<name>.ignore=all`. The only
1333 exception to that rule is that status and commit will show staged
1334 submodule changes. To
1335 also view the summary for ignored submodules you can either use
1336 the --ignore-submodules=dirty command-line option or the 'git
1337 submodule summary' command, which shows a similar output but does
1338 not honor these settings.
1341 If this is set to true, the `git stash show` command without an
1342 option will show the stash entry in patch form. Defaults to false.
1343 See description of 'show' command in linkgit:git-stash[1].
1346 If this is set to true, the `git stash show` command without an
1347 option will show diffstat of the stash entry. Defaults to true.
1348 See description of 'show' command in linkgit:git-stash[1].
1350 include::submodule-config.txt[]
1352 tag.forceSignAnnotated::
1353 A boolean to specify whether annotated tags created should be GPG signed.
1354 If `--annotate` is specified on the command line, it takes
1355 precedence over this option.
1358 This variable controls the sort ordering of tags when displayed by
1359 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
1360 value of this variable will be used as the default.
1363 This variable can be used to restrict the permission bits of
1364 tar archive entries. The default is 0002, which turns off the
1365 world write bit. The special value "user" indicates that the
1366 archiving user's umask will be used instead. See umask(2) and
1367 linkgit:git-archive[1].
1369 transfer.fsckObjects::
1370 When `fetch.fsckObjects` or `receive.fsckObjects` are
1371 not set, the value of this variable is used instead.
1374 When set, the fetch or receive will abort in the case of a malformed
1375 object or a link to a nonexistent object. In addition, various other
1376 issues are checked for, including legacy issues (see `fsck.<msg-id>`),
1377 and potential security issues like the existence of a `.GIT` directory
1378 or a malicious `.gitmodules` file (see the release notes for v2.2.1
1379 and v2.17.1 for details). Other sanity and security checks may be
1380 added in future releases.
1382 On the receiving side, failing fsckObjects will make those objects
1383 unreachable, see "QUARANTINE ENVIRONMENT" in
1384 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
1385 instead be left unreferenced in the repository.
1387 Due to the non-quarantine nature of the `fetch.fsckObjects`
1388 implementation it can not be relied upon to leave the object store
1389 clean like `receive.fsckObjects` can.
1391 As objects are unpacked they're written to the object store, so there
1392 can be cases where malicious objects get introduced even though the
1393 "fetch" failed, only to have a subsequent "fetch" succeed because only
1394 new incoming objects are checked, not those that have already been
1395 written to the object store. That difference in behavior should not be
1396 relied upon. In the future, such objects may be quarantined for
1399 For now, the paranoid need to find some way to emulate the quarantine
1400 environment if they'd like the same protection as "push". E.g. in the
1401 case of an internal mirror do the mirroring in two steps, one to fetch
1402 the untrusted objects, and then do a second "push" (which will use the
1403 quarantine) to another internal repo, and have internal clients
1404 consume this pushed-to repository, or embargo internal fetches and
1405 only allow them once a full "fsck" has run (and no new fetches have
1406 happened in the meantime).
1409 String(s) `receive-pack` and `upload-pack` use to decide which
1410 refs to omit from their initial advertisements. Use more than
1411 one definition to specify multiple prefix strings. A ref that is
1412 under the hierarchies listed in the value of this variable is
1413 excluded, and is hidden when responding to `git push` or `git
1414 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
1415 program-specific versions of this config.
1417 You may also include a `!` in front of the ref name to negate the entry,
1418 explicitly exposing it, even if an earlier entry marked it as hidden.
1419 If you have multiple hideRefs values, later entries override earlier ones
1420 (and entries in more-specific config files override less-specific ones).
1422 If a namespace is in use, the namespace prefix is stripped from each
1423 reference before it is matched against `transfer.hiderefs` patterns.
1424 For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
1425 the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
1426 is omitted from the advertisements but `refs/heads/master` and
1427 `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
1428 "have" lines. In order to match refs before stripping, add a `^` in front of
1429 the ref name. If you combine `!` and `^`, `!` must be specified first.
1431 Even if you hide refs, a client may still be able to steal the target
1432 objects via the techniques described in the "SECURITY" section of the
1433 linkgit:gitnamespaces[7] man page; it's best to keep private data in a
1434 separate repository.
1436 transfer.unpackLimit::
1437 When `fetch.unpackLimit` or `receive.unpackLimit` are
1438 not set, the value of this variable is used instead.
1439 The default value is 100.
1441 uploadarchive.allowUnreachable::
1442 If true, allow clients to use `git archive --remote` to request
1443 any tree, whether reachable from the ref tips or not. See the
1444 discussion in the "SECURITY" section of
1445 linkgit:git-upload-archive[1] for more details. Defaults to
1448 uploadpack.hideRefs::
1449 This variable is the same as `transfer.hideRefs`, but applies
1450 only to `upload-pack` (and so affects only fetches, not pushes).
1451 An attempt to fetch a hidden ref by `git fetch` will fail. See
1452 also `uploadpack.allowTipSHA1InWant`.
1454 uploadpack.allowTipSHA1InWant::
1455 When `uploadpack.hideRefs` is in effect, allow `upload-pack`
1456 to accept a fetch request that asks for an object at the tip
1457 of a hidden ref (by default, such a request is rejected).
1458 See also `uploadpack.hideRefs`. Even if this is false, a client
1459 may be able to steal objects via the techniques described in the
1460 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
1461 best to keep private data in a separate repository.
1463 uploadpack.allowReachableSHA1InWant::
1464 Allow `upload-pack` to accept a fetch request that asks for an
1465 object that is reachable from any ref tip. However, note that
1466 calculating object reachability is computationally expensive.
1467 Defaults to `false`. Even if this is false, a client may be able
1468 to steal objects via the techniques described in the "SECURITY"
1469 section of the linkgit:gitnamespaces[7] man page; it's best to
1470 keep private data in a separate repository.
1472 uploadpack.allowAnySHA1InWant::
1473 Allow `upload-pack` to accept a fetch request that asks for any
1475 Defaults to `false`.
1477 uploadpack.keepAlive::
1478 When `upload-pack` has started `pack-objects`, there may be a
1479 quiet period while `pack-objects` prepares the pack. Normally
1480 it would output progress information, but if `--quiet` was used
1481 for the fetch, `pack-objects` will output nothing at all until
1482 the pack data begins. Some clients and networks may consider
1483 the server to be hung and give up. Setting this option instructs
1484 `upload-pack` to send an empty keepalive packet every
1485 `uploadpack.keepAlive` seconds. Setting this option to 0
1486 disables keepalive packets entirely. The default is 5 seconds.
1488 uploadpack.packObjectsHook::
1489 If this option is set, when `upload-pack` would run
1490 `git pack-objects` to create a packfile for a client, it will
1491 run this shell command instead. The `pack-objects` command and
1492 arguments it _would_ have run (including the `git pack-objects`
1493 at the beginning) are appended to the shell command. The stdin
1494 and stdout of the hook are treated as if `pack-objects` itself
1495 was run. I.e., `upload-pack` will feed input intended for
1496 `pack-objects` to the hook, and expects a completed packfile on
1499 Note that this configuration variable is ignored if it is seen in the
1500 repository-level config (this is a safety measure against fetching from
1501 untrusted repositories).
1503 uploadpack.allowFilter::
1504 If this option is set, `upload-pack` will support partial
1505 clone and partial fetch object filtering.
1507 uploadpack.allowRefInWant::
1508 If this option is set, `upload-pack` will support the `ref-in-want`
1509 feature of the protocol version 2 `fetch` command. This feature
1510 is intended for the benefit of load-balanced servers which may
1511 not have the same view of what OIDs their refs point to due to
1514 url.<base>.insteadOf::
1515 Any URL that starts with this value will be rewritten to
1516 start, instead, with <base>. In cases where some site serves a
1517 large number of repositories, and serves them with multiple
1518 access methods, and some users need to use different access
1519 methods, this feature allows people to specify any of the
1520 equivalent URLs and have Git automatically rewrite the URL to
1521 the best alternative for the particular user, even for a
1522 never-before-seen repository on the site. When more than one
1523 insteadOf strings match a given URL, the longest match is used.
1525 Note that any protocol restrictions will be applied to the rewritten
1526 URL. If the rewrite changes the URL to use a custom protocol or remote
1527 helper, you may need to adjust the `protocol.*.allow` config to permit
1528 the request. In particular, protocols you expect to use for submodules
1529 must be set to `always` rather than the default of `user`. See the
1530 description of `protocol.allow` above.
1532 url.<base>.pushInsteadOf::
1533 Any URL that starts with this value will not be pushed to;
1534 instead, it will be rewritten to start with <base>, and the
1535 resulting URL will be pushed to. In cases where some site serves
1536 a large number of repositories, and serves them with multiple
1537 access methods, some of which do not allow push, this feature
1538 allows people to specify a pull-only URL and have Git
1539 automatically use an appropriate URL to push, even for a
1540 never-before-seen repository on the site. When more than one
1541 pushInsteadOf strings match a given URL, the longest match is
1542 used. If a remote has an explicit pushurl, Git will ignore this
1543 setting for that remote.
1546 Your email address to be recorded in any newly created commits.
1547 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
1548 `EMAIL` environment variables. See linkgit:git-commit-tree[1].
1551 Your full name to be recorded in any newly created commits.
1552 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
1553 environment variables. See linkgit:git-commit-tree[1].
1555 user.useConfigOnly::
1556 Instruct Git to avoid trying to guess defaults for `user.email`
1557 and `user.name`, and instead retrieve the values only from the
1558 configuration. For example, if you have multiple email addresses
1559 and would like to use a different one for each repository, then
1560 with this configuration option set to `true` in the global config
1561 along with a name, Git will prompt you to set up an email before
1562 making new commits in a newly cloned repository.
1563 Defaults to `false`.
1566 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
1567 key you want it to automatically when creating a signed tag or
1568 commit, you can override the default selection with this variable.
1569 This option is passed unchanged to gpg's --local-user parameter,
1570 so you may specify a key using any method that gpg supports.
1572 versionsort.prereleaseSuffix (deprecated)::
1573 Deprecated alias for `versionsort.suffix`. Ignored if
1574 `versionsort.suffix` is set.
1576 versionsort.suffix::
1577 Even when version sort is used in linkgit:git-tag[1], tagnames
1578 with the same base version but different suffixes are still sorted
1579 lexicographically, resulting e.g. in prerelease tags appearing
1580 after the main release (e.g. "1.0-rc1" after "1.0"). This
1581 variable can be specified to determine the sorting order of tags
1582 with different suffixes.
1584 By specifying a single suffix in this variable, any tagname containing
1585 that suffix will appear before the corresponding main release. E.g. if
1586 the variable is set to "-rc", then all "1.0-rcX" tags will appear before
1587 "1.0". If specified multiple times, once per suffix, then the order of
1588 suffixes in the configuration will determine the sorting order of tagnames
1589 with those suffixes. E.g. if "-pre" appears before "-rc" in the
1590 configuration, then all "1.0-preX" tags will be listed before any
1591 "1.0-rcX" tags. The placement of the main release tag relative to tags
1592 with various suffixes can be determined by specifying the empty suffix
1593 among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
1594 "-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
1595 are listed first, followed by "v4.8", then "v4.8-ckX" and finally
1598 If more than one suffixes match the same tagname, then that tagname will
1599 be sorted according to the suffix which starts at the earliest position in
1600 the tagname. If more than one different matching suffixes start at
1601 that earliest position, then that tagname will be sorted according to the
1602 longest of those suffixes.
1603 The sorting order between different suffixes is undefined if they are
1604 in multiple config files.
1607 Specify a web browser that may be used by some commands.
1608 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
1611 worktree.guessRemote::
1612 With `add`, if no branch argument, and neither of `-b` nor
1613 `-B` nor `--detach` are given, the command defaults to
1614 creating a new branch from HEAD. If `worktree.guessRemote` is
1615 set to true, `worktree add` tries to find a remote-tracking
1616 branch whose name uniquely matches the new branch name. If
1617 such a branch exists, it is checked out and set as "upstream"
1618 for the new branch. If no such match can be found, it falls
1619 back to creating a new branch from the current HEAD.