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[]
352 include::config/http.txt[]
354 include::config/i18n.txt[]
356 include::config/imap.txt[]
358 include::config/index.txt[]
360 include::config/init.txt[]
362 include::config/instaweb.txt[]
364 include::config/interactive.txt[]
366 include::config/log.txt[]
368 include::config/mailinfo.txt[]
370 include::config/mailmap.txt[]
372 include::config/man.txt[]
374 include::merge-config.txt[]
376 mergetool.<tool>.path::
377 Override the path for the given tool. This is useful in case
378 your tool is not in the PATH.
380 mergetool.<tool>.cmd::
381 Specify the command to invoke the specified merge tool. The
382 specified command is evaluated in shell with the following
383 variables available: 'BASE' is the name of a temporary file
384 containing the common base of the files to be merged, if available;
385 'LOCAL' is the name of a temporary file containing the contents of
386 the file on the current branch; 'REMOTE' is the name of a temporary
387 file containing the contents of the file from the branch being
388 merged; 'MERGED' contains the name of the file to which the merge
389 tool should write the results of a successful merge.
391 mergetool.<tool>.trustExitCode::
392 For a custom merge command, specify whether the exit code of
393 the merge command can be used to determine whether the merge was
394 successful. If this is not set to true then the merge target file
395 timestamp is checked and the merge assumed to have been successful
396 if the file has been updated, otherwise the user is prompted to
397 indicate the success of the merge.
399 mergetool.meld.hasOutput::
400 Older versions of `meld` do not support the `--output` option.
401 Git will attempt to detect whether `meld` supports `--output`
402 by inspecting the output of `meld --help`. Configuring
403 `mergetool.meld.hasOutput` will make Git skip these checks and
404 use the configured value instead. Setting `mergetool.meld.hasOutput`
405 to `true` tells Git to unconditionally use the `--output` option,
406 and `false` avoids using `--output`.
408 mergetool.keepBackup::
409 After performing a merge, the original file with conflict markers
410 can be saved as a file with a `.orig` extension. If this variable
411 is set to `false` then this file is not preserved. Defaults to
412 `true` (i.e. keep the backup files).
414 mergetool.keepTemporaries::
415 When invoking a custom merge tool, Git uses a set of temporary
416 files to pass to the tool. If the tool returns an error and this
417 variable is set to `true`, then these temporary files will be
418 preserved, otherwise they will be removed after the tool has
419 exited. Defaults to `false`.
421 mergetool.writeToTemp::
422 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
423 conflicting files in the worktree by default. Git will attempt
424 to use a temporary directory for these files when set `true`.
428 Prompt before each invocation of the merge resolution program.
430 notes.mergeStrategy::
431 Which merge strategy to choose by default when resolving notes
432 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
433 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
434 section of linkgit:git-notes[1] for more information on each strategy.
436 notes.<name>.mergeStrategy::
437 Which merge strategy to choose when doing a notes merge into
438 refs/notes/<name>. This overrides the more general
439 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
440 linkgit:git-notes[1] for more information on the available strategies.
443 The (fully qualified) refname from which to show notes when
444 showing commit messages. The value of this variable can be set
445 to a glob, in which case notes from all matching refs will be
446 shown. You may also specify this configuration variable
447 several times. A warning will be issued for refs that do not
448 exist, but a glob that does not match any refs is silently
451 This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
452 environment variable, which must be a colon separated list of refs or
455 The effective value of "core.notesRef" (possibly overridden by
456 GIT_NOTES_REF) is also implicitly added to the list of refs to be
459 notes.rewrite.<command>::
460 When rewriting commits with <command> (currently `amend` or
461 `rebase`) and this variable is set to `true`, Git
462 automatically copies your notes from the original to the
463 rewritten commit. Defaults to `true`, but see
464 "notes.rewriteRef" below.
467 When copying notes during a rewrite (see the
468 "notes.rewrite.<command>" option), determines what to do if
469 the target commit already has a note. Must be one of
470 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
471 Defaults to `concatenate`.
473 This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
474 environment variable.
477 When copying notes during a rewrite, specifies the (fully
478 qualified) ref whose notes should be copied. The ref may be a
479 glob, in which case notes in all matching refs will be copied.
480 You may also specify this configuration several times.
482 Does not have a default value; you must configure this variable to
483 enable note rewriting. Set it to `refs/notes/commits` to enable
484 rewriting for the default commit notes.
486 This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
487 environment variable, which must be a colon separated list of refs or
491 The size of the window used by linkgit:git-pack-objects[1] when no
492 window size is given on the command line. Defaults to 10.
495 The maximum delta depth used by linkgit:git-pack-objects[1] when no
496 maximum depth is given on the command line. Defaults to 50.
497 Maximum value is 4095.
500 The maximum size of memory that is consumed by each thread
501 in linkgit:git-pack-objects[1] for pack window memory when
502 no limit is given on the command line. The value can be
503 suffixed with "k", "m", or "g". When left unconfigured (or
504 set explicitly to 0), there will be no limit.
507 An integer -1..9, indicating the compression level for objects
508 in a pack file. -1 is the zlib default. 0 means no
509 compression, and 1..9 are various speed/size tradeoffs, 9 being
510 slowest. If not set, defaults to core.compression. If that is
511 not set, defaults to -1, the zlib default, which is "a default
512 compromise between speed and compression (currently equivalent
515 Note that changing the compression level will not automatically recompress
516 all existing objects. You can force recompression by passing the -F option
517 to linkgit:git-repack[1].
520 An extended regular expression configuring a set of delta
521 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
525 Specify an island name which gets to have its objects be
526 packed first. This creates a kind of pseudo-pack at the front
527 of one pack, so that the objects from the specified island are
528 hopefully faster to copy into any pack that should be served
529 to a user requesting these objects. In practice this means
530 that the island specified should likely correspond to what is
531 the most commonly cloned in the repo. See also "DELTA ISLANDS"
532 in linkgit:git-pack-objects[1].
534 pack.deltaCacheSize::
535 The maximum memory in bytes used for caching deltas in
536 linkgit:git-pack-objects[1] before writing them out to a pack.
537 This cache is used to speed up the writing object phase by not
538 having to recompute the final delta result once the best match
539 for all objects is found. Repacking large repositories on machines
540 which are tight with memory might be badly impacted by this though,
541 especially if this cache pushes the system into swapping.
542 A value of 0 means no limit. The smallest size of 1 byte may be
543 used to virtually disable this cache. Defaults to 256 MiB.
545 pack.deltaCacheLimit::
546 The maximum size of a delta, that is cached in
547 linkgit:git-pack-objects[1]. This cache is used to speed up the
548 writing object phase by not having to recompute the final delta
549 result once the best match for all objects is found.
550 Defaults to 1000. Maximum value is 65535.
553 Specifies the number of threads to spawn when searching for best
554 delta matches. This requires that linkgit:git-pack-objects[1]
555 be compiled with pthreads otherwise this option is ignored with a
556 warning. This is meant to reduce packing time on multiprocessor
557 machines. The required amount of memory for the delta search window
558 is however multiplied by the number of threads.
559 Specifying 0 will cause Git to auto-detect the number of CPU's
560 and set the number of threads accordingly.
563 Specify the default pack index version. Valid values are 1 for
564 legacy pack index used by Git versions prior to 1.5.2, and 2 for
565 the new pack index with capabilities for packs larger than 4 GB
566 as well as proper protection against the repacking of corrupted
567 packs. Version 2 is the default. Note that version 2 is enforced
568 and this config option ignored whenever the corresponding pack is
571 If you have an old Git that does not understand the version 2 `*.idx` file,
572 cloning or fetching over a non native protocol (e.g. "http")
573 that will copy both `*.pack` file and corresponding `*.idx` file from the
574 other side may give you a repository that cannot be accessed with your
575 older version of Git. If the `*.pack` file is smaller than 2 GB, however,
576 you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
580 The maximum size of a pack. This setting only affects
581 packing to a file when repacking, i.e. the git:// protocol
582 is unaffected. It can be overridden by the `--max-pack-size`
583 option of linkgit:git-repack[1]. Reaching this limit results
584 in the creation of multiple packfiles; which in turn prevents
585 bitmaps from being created.
586 The minimum size allowed is limited to 1 MiB.
587 The default is unlimited.
588 Common unit suffixes of 'k', 'm', or 'g' are
592 When true, git will use pack bitmaps (if available) when packing
593 to stdout (e.g., during the server side of a fetch). Defaults to
594 true. You should not generally need to turn this off unless
595 you are debugging pack bitmaps.
597 pack.writeBitmaps (deprecated)::
598 This is a deprecated synonym for `repack.writeBitmaps`.
600 pack.writeBitmapHashCache::
601 When true, git will include a "hash cache" section in the bitmap
602 index (if one is written). This cache can be used to feed git's
603 delta heuristics, potentially leading to better deltas between
604 bitmapped and non-bitmapped objects (e.g., when serving a fetch
605 between an older, bitmapped pack and objects that have been
606 pushed since the last gc). The downside is that it consumes 4
607 bytes per object of disk space, and that JGit's bitmap
608 implementation does not understand it, causing it to complain if
609 Git and JGit are used on the same repository. Defaults to false.
612 If the value is boolean, turns on or off pagination of the
613 output of a particular Git subcommand when writing to a tty.
614 Otherwise, turns on pagination for the subcommand using the
615 pager specified by the value of `pager.<cmd>`. If `--paginate`
616 or `--no-pager` is specified on the command line, it takes
617 precedence over this option. To disable pagination for all
618 commands, set `core.pager` or `GIT_PAGER` to `cat`.
621 Alias for a --pretty= format string, as specified in
622 linkgit:git-log[1]. Any aliases defined here can be used just
623 as the built-in pretty formats could. For example,
624 running `git config pretty.changelog "format:* %H %s"`
625 would cause the invocation `git log --pretty=changelog`
626 to be equivalent to running `git log "--pretty=format:* %H %s"`.
627 Note that an alias with the same name as a built-in format
628 will be silently ignored.
631 If set, provide a user defined default policy for all protocols which
632 don't explicitly have a policy (`protocol.<name>.allow`). By default,
633 if unset, known-safe protocols (http, https, git, ssh, file) have a
634 default policy of `always`, known-dangerous protocols (ext) have a
635 default policy of `never`, and all other protocols have a default
636 policy of `user`. Supported policies:
640 * `always` - protocol is always able to be used.
642 * `never` - protocol is never able to be used.
644 * `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
645 either unset or has a value of 1. This policy should be used when you want a
646 protocol to be directly usable by the user but don't want it used by commands which
647 execute clone/fetch/push commands without user input, e.g. recursive
648 submodule initialization.
652 protocol.<name>.allow::
653 Set a policy to be used by protocol `<name>` with clone/fetch/push
654 commands. See `protocol.allow` above for the available policies.
656 The protocol names currently used by git are:
659 - `file`: any local file-based path (including `file://` URLs,
662 - `git`: the anonymous git protocol over a direct TCP
663 connection (or proxy, if configured)
665 - `ssh`: git over ssh (including `host:path` syntax,
668 - `http`: git over http, both "smart http" and "dumb http".
669 Note that this does _not_ include `https`; if you want to configure
670 both, you must do so individually.
672 - any external helpers are named by their protocol (e.g., use
673 `hg` to allow the `git-remote-hg` helper)
677 Experimental. If set, clients will attempt to communicate with a
678 server using the specified protocol version. If unset, no
679 attempt will be made by the client to communicate using a
680 particular protocol version, this results in protocol version 0
686 * `0` - the original wire protocol.
688 * `1` - the original wire protocol with the addition of a version string
689 in the initial response from the server.
691 * `2` - link:technical/protocol-v2.html[wire protocol version 2].
695 include::pull-config.txt[]
697 include::push-config.txt[]
699 include::rebase-config.txt[]
701 include::receive-config.txt[]
704 The remote to push to by default. Overrides
705 `branch.<name>.remote` for all branches, and is overridden by
706 `branch.<name>.pushRemote` for specific branches.
709 The URL of a remote repository. See linkgit:git-fetch[1] or
712 remote.<name>.pushurl::
713 The push URL of a remote repository. See linkgit:git-push[1].
715 remote.<name>.proxy::
716 For remotes that require curl (http, https and ftp), the URL to
717 the proxy to use for that remote. Set to the empty string to
718 disable proxying for that remote.
720 remote.<name>.proxyAuthMethod::
721 For remotes that require curl (http, https and ftp), the method to use for
722 authenticating against the proxy in use (probably set in
723 `remote.<name>.proxy`). See `http.proxyAuthMethod`.
725 remote.<name>.fetch::
726 The default set of "refspec" for linkgit:git-fetch[1]. See
727 linkgit:git-fetch[1].
730 The default set of "refspec" for linkgit:git-push[1]. See
733 remote.<name>.mirror::
734 If true, pushing to this remote will automatically behave
735 as if the `--mirror` option was given on the command line.
737 remote.<name>.skipDefaultUpdate::
738 If true, this remote will be skipped by default when updating
739 using linkgit:git-fetch[1] or the `update` subcommand of
740 linkgit:git-remote[1].
742 remote.<name>.skipFetchAll::
743 If true, this remote will be skipped by default when updating
744 using linkgit:git-fetch[1] or the `update` subcommand of
745 linkgit:git-remote[1].
747 remote.<name>.receivepack::
748 The default program to execute on the remote side when pushing. See
749 option --receive-pack of linkgit:git-push[1].
751 remote.<name>.uploadpack::
752 The default program to execute on the remote side when fetching. See
753 option --upload-pack of linkgit:git-fetch-pack[1].
755 remote.<name>.tagOpt::
756 Setting this value to --no-tags disables automatic tag following when
757 fetching from remote <name>. Setting it to --tags will fetch every
758 tag from remote <name>, even if they are not reachable from remote
759 branch heads. Passing these flags directly to linkgit:git-fetch[1] can
760 override this setting. See options --tags and --no-tags of
761 linkgit:git-fetch[1].
764 Setting this to a value <vcs> will cause Git to interact with
765 the remote with the git-remote-<vcs> helper.
767 remote.<name>.prune::
768 When set to true, fetching from this remote by default will also
769 remove any remote-tracking references that no longer exist on the
770 remote (as if the `--prune` option was given on the command line).
771 Overrides `fetch.prune` settings, if any.
773 remote.<name>.pruneTags::
774 When set to true, fetching from this remote by default will also
775 remove any local tags that no longer exist on the remote if pruning
776 is activated in general via `remote.<name>.prune`, `fetch.prune` or
777 `--prune`. Overrides `fetch.pruneTags` settings, if any.
779 See also `remote.<name>.prune` and the PRUNING section of
780 linkgit:git-fetch[1].
783 The list of remotes which are fetched by "git remote update
784 <group>". See linkgit:git-remote[1].
786 repack.useDeltaBaseOffset::
787 By default, linkgit:git-repack[1] creates packs that use
788 delta-base offset. If you need to share your repository with
789 Git older than version 1.4.4, either directly or via a dumb
790 protocol such as http, then you need to set this option to
791 "false" and repack. Access from old Git versions over the
792 native protocol are unaffected by this option.
794 repack.packKeptObjects::
795 If set to true, makes `git repack` act as if
796 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
797 details. Defaults to `false` normally, but `true` if a bitmap
798 index is being written (either via `--write-bitmap-index` or
799 `repack.writeBitmaps`).
801 repack.useDeltaIslands::
802 If set to true, makes `git repack` act as if `--delta-islands`
803 was passed. Defaults to `false`.
805 repack.writeBitmaps::
806 When true, git will write a bitmap index when packing all
807 objects to disk (e.g., when `git repack -a` is run). This
808 index can speed up the "counting objects" phase of subsequent
809 packs created for clones and fetches, at the cost of some disk
810 space and extra time spent on the initial repack. This has
811 no effect if multiple packfiles are created.
815 When set to true, `git-rerere` updates the index with the
816 resulting contents after it cleanly resolves conflicts using
817 previously recorded resolution. Defaults to false.
820 Activate recording of resolved conflicts, so that identical
821 conflict hunks can be resolved automatically, should they be
822 encountered again. By default, linkgit:git-rerere[1] is
823 enabled if there is an `rr-cache` directory under the
824 `$GIT_DIR`, e.g. if "rerere" was previously used in the
828 When set to true, 'git reset' will default to the '--quiet' option.
830 include::sendemail-config.txt[]
833 Text editor used by `git rebase -i` for editing the rebase instruction file.
834 The value is meant to be interpreted by the shell when it is used.
835 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
836 When not configured the default commit message editor is used instead.
839 The default set of branches for linkgit:git-show-branch[1].
840 See linkgit:git-show-branch[1].
842 splitIndex.maxPercentChange::
843 When the split index feature is used, this specifies the
844 percent of entries the split index can contain compared to the
845 total number of entries in both the split index and the shared
846 index before a new shared index is written.
847 The value should be between 0 and 100. If the value is 0 then
848 a new shared index is always written, if it is 100 a new
849 shared index is never written.
850 By default the value is 20, so a new shared index is written
851 if the number of entries in the split index would be greater
852 than 20 percent of the total number of entries.
853 See linkgit:git-update-index[1].
855 splitIndex.sharedIndexExpire::
856 When the split index feature is used, shared index files that
857 were not modified since the time this variable specifies will
858 be removed when a new shared index file is created. The value
859 "now" expires all entries immediately, and "never" suppresses
860 expiration altogether.
861 The default value is "2.weeks.ago".
862 Note that a shared index file is considered modified (for the
863 purpose of expiration) each time a new split-index file is
864 either created based on it or read from it.
865 See linkgit:git-update-index[1].
867 include::config/ssh.txt[]
869 status.relativePaths::
870 By default, linkgit:git-status[1] shows paths relative to the
871 current directory. Setting this variable to `false` shows paths
872 relative to the repository root (this was the default for Git
876 Set to true to enable --short by default in linkgit:git-status[1].
877 The option --no-short takes precedence over this variable.
880 Set to true to enable --branch by default in linkgit:git-status[1].
881 The option --no-branch takes precedence over this variable.
883 status.displayCommentPrefix::
884 If set to true, linkgit:git-status[1] will insert a comment
885 prefix before each output line (starting with
886 `core.commentChar`, i.e. `#` by default). This was the
887 behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
891 The number of files to consider when performing rename detection
892 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
893 the value of diff.renameLimit.
896 Whether and how Git detects renames in linkgit:git-status[1] and
897 linkgit:git-commit[1] . If set to "false", rename detection is
898 disabled. If set to "true", basic rename detection is enabled.
899 If set to "copies" or "copy", Git will detect copies, as well.
900 Defaults to the value of diff.renames.
903 If set to true, linkgit:git-status[1] will display the number of
904 entries currently stashed away.
907 status.showUntrackedFiles::
908 By default, linkgit:git-status[1] and linkgit:git-commit[1] show
909 files which are not currently tracked by Git. Directories which
910 contain only untracked files, are shown with the directory name
911 only. Showing untracked files means that Git needs to lstat() all
912 the files in the whole repository, which might be slow on some
913 systems. So, this variable controls how the commands displays
914 the untracked files. Possible values are:
917 * `no` - Show no untracked files.
918 * `normal` - Show untracked files and directories.
919 * `all` - Show also individual files in untracked directories.
922 If this variable is not specified, it defaults to 'normal'.
923 This variable can be overridden with the -u|--untracked-files option
924 of linkgit:git-status[1] and linkgit:git-commit[1].
926 status.submoduleSummary::
928 If this is set to a non zero number or true (identical to -1 or an
929 unlimited number), the submodule summary will be enabled and a
930 summary of commits for modified submodules will be shown (see
931 --summary-limit option of linkgit:git-submodule[1]). Please note
932 that the summary output command will be suppressed for all
933 submodules when `diff.ignoreSubmodules` is set to 'all' or only
934 for those submodules where `submodule.<name>.ignore=all`. The only
935 exception to that rule is that status and commit will show staged
936 submodule changes. To
937 also view the summary for ignored submodules you can either use
938 the --ignore-submodules=dirty command-line option or the 'git
939 submodule summary' command, which shows a similar output but does
940 not honor these settings.
943 If this is set to true, the `git stash show` command without an
944 option will show the stash entry in patch form. Defaults to false.
945 See description of 'show' command in linkgit:git-stash[1].
948 If this is set to true, the `git stash show` command without an
949 option will show diffstat of the stash entry. Defaults to true.
950 See description of 'show' command in linkgit:git-stash[1].
952 include::submodule-config.txt[]
954 tag.forceSignAnnotated::
955 A boolean to specify whether annotated tags created should be GPG signed.
956 If `--annotate` is specified on the command line, it takes
957 precedence over this option.
960 This variable controls the sort ordering of tags when displayed by
961 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
962 value of this variable will be used as the default.
965 This variable can be used to restrict the permission bits of
966 tar archive entries. The default is 0002, which turns off the
967 world write bit. The special value "user" indicates that the
968 archiving user's umask will be used instead. See umask(2) and
969 linkgit:git-archive[1].
971 transfer.fsckObjects::
972 When `fetch.fsckObjects` or `receive.fsckObjects` are
973 not set, the value of this variable is used instead.
976 When set, the fetch or receive will abort in the case of a malformed
977 object or a link to a nonexistent object. In addition, various other
978 issues are checked for, including legacy issues (see `fsck.<msg-id>`),
979 and potential security issues like the existence of a `.GIT` directory
980 or a malicious `.gitmodules` file (see the release notes for v2.2.1
981 and v2.17.1 for details). Other sanity and security checks may be
982 added in future releases.
984 On the receiving side, failing fsckObjects will make those objects
985 unreachable, see "QUARANTINE ENVIRONMENT" in
986 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
987 instead be left unreferenced in the repository.
989 Due to the non-quarantine nature of the `fetch.fsckObjects`
990 implementation it can not be relied upon to leave the object store
991 clean like `receive.fsckObjects` can.
993 As objects are unpacked they're written to the object store, so there
994 can be cases where malicious objects get introduced even though the
995 "fetch" failed, only to have a subsequent "fetch" succeed because only
996 new incoming objects are checked, not those that have already been
997 written to the object store. That difference in behavior should not be
998 relied upon. In the future, such objects may be quarantined for
1001 For now, the paranoid need to find some way to emulate the quarantine
1002 environment if they'd like the same protection as "push". E.g. in the
1003 case of an internal mirror do the mirroring in two steps, one to fetch
1004 the untrusted objects, and then do a second "push" (which will use the
1005 quarantine) to another internal repo, and have internal clients
1006 consume this pushed-to repository, or embargo internal fetches and
1007 only allow them once a full "fsck" has run (and no new fetches have
1008 happened in the meantime).
1011 String(s) `receive-pack` and `upload-pack` use to decide which
1012 refs to omit from their initial advertisements. Use more than
1013 one definition to specify multiple prefix strings. A ref that is
1014 under the hierarchies listed in the value of this variable is
1015 excluded, and is hidden when responding to `git push` or `git
1016 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
1017 program-specific versions of this config.
1019 You may also include a `!` in front of the ref name to negate the entry,
1020 explicitly exposing it, even if an earlier entry marked it as hidden.
1021 If you have multiple hideRefs values, later entries override earlier ones
1022 (and entries in more-specific config files override less-specific ones).
1024 If a namespace is in use, the namespace prefix is stripped from each
1025 reference before it is matched against `transfer.hiderefs` patterns.
1026 For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
1027 the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
1028 is omitted from the advertisements but `refs/heads/master` and
1029 `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
1030 "have" lines. In order to match refs before stripping, add a `^` in front of
1031 the ref name. If you combine `!` and `^`, `!` must be specified first.
1033 Even if you hide refs, a client may still be able to steal the target
1034 objects via the techniques described in the "SECURITY" section of the
1035 linkgit:gitnamespaces[7] man page; it's best to keep private data in a
1036 separate repository.
1038 transfer.unpackLimit::
1039 When `fetch.unpackLimit` or `receive.unpackLimit` are
1040 not set, the value of this variable is used instead.
1041 The default value is 100.
1043 uploadarchive.allowUnreachable::
1044 If true, allow clients to use `git archive --remote` to request
1045 any tree, whether reachable from the ref tips or not. See the
1046 discussion in the "SECURITY" section of
1047 linkgit:git-upload-archive[1] for more details. Defaults to
1050 uploadpack.hideRefs::
1051 This variable is the same as `transfer.hideRefs`, but applies
1052 only to `upload-pack` (and so affects only fetches, not pushes).
1053 An attempt to fetch a hidden ref by `git fetch` will fail. See
1054 also `uploadpack.allowTipSHA1InWant`.
1056 uploadpack.allowTipSHA1InWant::
1057 When `uploadpack.hideRefs` is in effect, allow `upload-pack`
1058 to accept a fetch request that asks for an object at the tip
1059 of a hidden ref (by default, such a request is rejected).
1060 See also `uploadpack.hideRefs`. Even if this is false, a client
1061 may be able to steal objects via the techniques described in the
1062 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
1063 best to keep private data in a separate repository.
1065 uploadpack.allowReachableSHA1InWant::
1066 Allow `upload-pack` to accept a fetch request that asks for an
1067 object that is reachable from any ref tip. However, note that
1068 calculating object reachability is computationally expensive.
1069 Defaults to `false`. Even if this is false, a client may be able
1070 to steal objects via the techniques described in the "SECURITY"
1071 section of the linkgit:gitnamespaces[7] man page; it's best to
1072 keep private data in a separate repository.
1074 uploadpack.allowAnySHA1InWant::
1075 Allow `upload-pack` to accept a fetch request that asks for any
1077 Defaults to `false`.
1079 uploadpack.keepAlive::
1080 When `upload-pack` has started `pack-objects`, there may be a
1081 quiet period while `pack-objects` prepares the pack. Normally
1082 it would output progress information, but if `--quiet` was used
1083 for the fetch, `pack-objects` will output nothing at all until
1084 the pack data begins. Some clients and networks may consider
1085 the server to be hung and give up. Setting this option instructs
1086 `upload-pack` to send an empty keepalive packet every
1087 `uploadpack.keepAlive` seconds. Setting this option to 0
1088 disables keepalive packets entirely. The default is 5 seconds.
1090 uploadpack.packObjectsHook::
1091 If this option is set, when `upload-pack` would run
1092 `git pack-objects` to create a packfile for a client, it will
1093 run this shell command instead. The `pack-objects` command and
1094 arguments it _would_ have run (including the `git pack-objects`
1095 at the beginning) are appended to the shell command. The stdin
1096 and stdout of the hook are treated as if `pack-objects` itself
1097 was run. I.e., `upload-pack` will feed input intended for
1098 `pack-objects` to the hook, and expects a completed packfile on
1101 Note that this configuration variable is ignored if it is seen in the
1102 repository-level config (this is a safety measure against fetching from
1103 untrusted repositories).
1105 uploadpack.allowFilter::
1106 If this option is set, `upload-pack` will support partial
1107 clone and partial fetch object filtering.
1109 uploadpack.allowRefInWant::
1110 If this option is set, `upload-pack` will support the `ref-in-want`
1111 feature of the protocol version 2 `fetch` command. This feature
1112 is intended for the benefit of load-balanced servers which may
1113 not have the same view of what OIDs their refs point to due to
1116 url.<base>.insteadOf::
1117 Any URL that starts with this value will be rewritten to
1118 start, instead, with <base>. In cases where some site serves a
1119 large number of repositories, and serves them with multiple
1120 access methods, and some users need to use different access
1121 methods, this feature allows people to specify any of the
1122 equivalent URLs and have Git automatically rewrite the URL to
1123 the best alternative for the particular user, even for a
1124 never-before-seen repository on the site. When more than one
1125 insteadOf strings match a given URL, the longest match is used.
1127 Note that any protocol restrictions will be applied to the rewritten
1128 URL. If the rewrite changes the URL to use a custom protocol or remote
1129 helper, you may need to adjust the `protocol.*.allow` config to permit
1130 the request. In particular, protocols you expect to use for submodules
1131 must be set to `always` rather than the default of `user`. See the
1132 description of `protocol.allow` above.
1134 url.<base>.pushInsteadOf::
1135 Any URL that starts with this value will not be pushed to;
1136 instead, it will be rewritten to start with <base>, and the
1137 resulting URL will be pushed to. In cases where some site serves
1138 a large number of repositories, and serves them with multiple
1139 access methods, some of which do not allow push, this feature
1140 allows people to specify a pull-only URL and have Git
1141 automatically use an appropriate URL to push, even for a
1142 never-before-seen repository on the site. When more than one
1143 pushInsteadOf strings match a given URL, the longest match is
1144 used. If a remote has an explicit pushurl, Git will ignore this
1145 setting for that remote.
1148 Your email address to be recorded in any newly created commits.
1149 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
1150 `EMAIL` environment variables. See linkgit:git-commit-tree[1].
1153 Your full name to be recorded in any newly created commits.
1154 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
1155 environment variables. See linkgit:git-commit-tree[1].
1157 user.useConfigOnly::
1158 Instruct Git to avoid trying to guess defaults for `user.email`
1159 and `user.name`, and instead retrieve the values only from the
1160 configuration. For example, if you have multiple email addresses
1161 and would like to use a different one for each repository, then
1162 with this configuration option set to `true` in the global config
1163 along with a name, Git will prompt you to set up an email before
1164 making new commits in a newly cloned repository.
1165 Defaults to `false`.
1168 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
1169 key you want it to automatically when creating a signed tag or
1170 commit, you can override the default selection with this variable.
1171 This option is passed unchanged to gpg's --local-user parameter,
1172 so you may specify a key using any method that gpg supports.
1174 versionsort.prereleaseSuffix (deprecated)::
1175 Deprecated alias for `versionsort.suffix`. Ignored if
1176 `versionsort.suffix` is set.
1178 versionsort.suffix::
1179 Even when version sort is used in linkgit:git-tag[1], tagnames
1180 with the same base version but different suffixes are still sorted
1181 lexicographically, resulting e.g. in prerelease tags appearing
1182 after the main release (e.g. "1.0-rc1" after "1.0"). This
1183 variable can be specified to determine the sorting order of tags
1184 with different suffixes.
1186 By specifying a single suffix in this variable, any tagname containing
1187 that suffix will appear before the corresponding main release. E.g. if
1188 the variable is set to "-rc", then all "1.0-rcX" tags will appear before
1189 "1.0". If specified multiple times, once per suffix, then the order of
1190 suffixes in the configuration will determine the sorting order of tagnames
1191 with those suffixes. E.g. if "-pre" appears before "-rc" in the
1192 configuration, then all "1.0-preX" tags will be listed before any
1193 "1.0-rcX" tags. The placement of the main release tag relative to tags
1194 with various suffixes can be determined by specifying the empty suffix
1195 among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
1196 "-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
1197 are listed first, followed by "v4.8", then "v4.8-ckX" and finally
1200 If more than one suffixes match the same tagname, then that tagname will
1201 be sorted according to the suffix which starts at the earliest position in
1202 the tagname. If more than one different matching suffixes start at
1203 that earliest position, then that tagname will be sorted according to the
1204 longest of those suffixes.
1205 The sorting order between different suffixes is undefined if they are
1206 in multiple config files.
1209 Specify a web browser that may be used by some commands.
1210 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
1213 worktree.guessRemote::
1214 With `add`, if no branch argument, and neither of `-b` nor
1215 `-B` nor `--detach` are given, the command defaults to
1216 creating a new branch from HEAD. If `worktree.guessRemote` is
1217 set to true, `worktree add` tries to find a remote-tracking
1218 branch whose name uniquely matches the new branch name. If
1219 such a branch exists, it is checked out and set as "upstream"
1220 for the new branch. If no such match can be found, it falls
1221 back to creating a new branch from the current HEAD.