1CONFIGURATION FILE 2------------------ 3 4The Git configuration file contains a number of variables that affect 5the Git commands' behavior. The `.git/config` file in each repository 6is used to store the configuration for that repository, and 7`$HOME/.gitconfig` is used to store a per-user configuration as 8fallback values for the `.git/config` file. The file `/etc/gitconfig` 9can be used to store a system-wide default configuration. 10 11The configuration variables are used by both the Git plumbing 12and the porcelains. The variables are divided into sections, wherein 13the fully qualified variable name of the variable itself is the last 14dot-separated segment and the section name is everything before the last 15dot. The variable names are case-insensitive, allow only alphanumeric 16characters and `-`, and must start with an alphabetic character. Some 17variables may appear multiple times; we say then that the variable is 18multivalued. 19 20Syntax 21~~~~~~ 22 23The syntax is fairly flexible and permissive; whitespaces are mostly 24ignored. The '#' and ';' characters begin comments to the end of line, 25blank lines are ignored. 26 27The file consists of sections and variables. A section begins with 28the name of the section in square brackets and continues until the next 29section begins. Section names are case-insensitive. Only alphanumeric 30characters, `-` and `.` are allowed in section names. Each variable 31must belong to some section, which means that there must be a section 32header before the first setting of a variable. 33 34Sections can be further divided into subsections. To begin a subsection 35put its name in double quotes, separated by space from the section name, 36in the section header, like in the example below: 37 38-------- 39 [section "subsection"] 40 41-------- 42 43Subsection names are case sensitive and can contain any characters except 44newline and the null byte. Doublequote `"` and backslash can be included 45by escaping them as `\"` and `\\`, respectively. Backslashes preceding 46other 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. 48Variables may belong directly to a section or to a given subsection. You 49can have `[section]` if you have `[section "subsection"]`, but you don't 50need to. 51 52There is also a deprecated `[section.subsection]` syntax. With this 53syntax, the subsection name is converted to lower-case and is also 54compared case sensitively. These subsection names follow the same 55restrictions as section names. 56 57All the other lines (and the remainder of the line after the section 58header) are recognized as setting variables, in the form 59'name = value' (or just 'name', which is a short-hand to say that 60the variable is the boolean "true"). 61The variable names are case-insensitive, allow only alphanumeric characters 62and `-`, and must start with an alphabetic character. 63 64A line that defines a value can be continued to the next line by 65ending it with a `\`; the backquote and the end-of-line are 66stripped. Leading whitespaces after 'name =', the remainder of the 67line after the first comment character '#' or ';', and trailing 68whitespaces of the line are discarded unless they are enclosed in 69double quotes. Internal whitespaces within the value are retained 70verbatim. 71 72Inside double quotes, double quote `"` and backslash `\` characters 73must be escaped: use `\"` for `"` and `\\` for `\`. 74 75The following escape sequences (beside `\"` and `\\`) are recognized: 76`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB) 77and `\b` for backspace (BS). Other char escape sequences (including octal 78escape sequences) are invalid. 79 80 81Includes 82~~~~~~~~ 83 84The `include` and `includeIf` sections allow you to include config 85directives from another source. These sections behave identically to 86each other with the exception that `includeIf` sections may be ignored 87if their condition does not evaluate to true; see "Conditional includes" 88below. 89 90You can include a config file from another by setting the special 91`include.path` (or `includeIf.*.path`) variable to the name of the file 92to be included. The variable takes a pathname as its value, and is 93subject to tilde expansion. These variables can be given multiple times. 94 95The contents of the included file are inserted immediately, as if they 96had been found at the location of the include directive. If the value of the 97variable is a relative path, the path is considered to 98be relative to the configuration file in which the include directive 99was found. See below for examples. 100 101Conditional includes 102~~~~~~~~~~~~~~~~~~~~ 103 104You can include a config file from another conditionally by setting a 105`includeIf.<condition>.path` variable to the name of the file to be 106included. 107 108The condition starts with a keyword followed by a colon and some data 109whose format and meaning depends on the keyword. Supported keywords 110are: 111 112`gitdir`:: 113 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. 117+ 118The .git location may be auto-discovered, or come from `$GIT_DIR` 119environment variable. If the repository is auto discovered via a .git 120file (e.g. from submodules, or a linked worktree), the .git location 121would be the final location where the .git directory is, not where the 122.git file is. 123+ 124The pattern can contain standard globbing wildcards and two additional 125ones, `**/` and `/**`, that can match multiple path components. Please 126refer to linkgit:gitignore[5] for details. For convenience: 127 128 * If the pattern starts with `~/`, `~` will be substituted with the 129 content of the environment variable `HOME`. 130 131 * If the pattern starts with `./`, it is replaced with the directory 132 containing the current config file. 133 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`. 137 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. 141 142`gitdir/i`:: 143 This is the same as `gitdir` except that matching is done 144 case-insensitively (e.g. on case-insensitive file sytems) 145 146A few more notes on matching via `gitdir` and `gitdir/i`: 147 148 * Symlinks in `$GIT_DIR` are not resolved before matching. 149 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` 153 will match. 154+ 155This was not the case in the initial release of this feature in 156v2.13.0, which only matched the realpath version. Configuration that 157wants to be compatible with the initial release of this feature needs 158to either specify only the realpath version, or both versions. 159 160 * Note that "../" is not special and will match literally, which is 161 unlikely what you want. 162 163Example 164~~~~~~~ 165 166 # Core variables 167 [core] 168 ; Don't trust file modes 169 filemode = false 170 171 # Our diff algorithm 172 [diff] 173 external = /usr/local/bin/diff-wrapper 174 renames = true 175 176 [branch "devel"] 177 remote = origin 178 merge = refs/heads/devel 179 180 # Proxy settings 181 [core] 182 gitProxy="ssh" for "kernel.org" 183 gitProxy=default-proxy ; for the rest 184 185 [include] 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 189 190 ; include if $GIT_DIR is /path/to/foo/.git 191 [includeIf "gitdir:/path/to/foo/.git"] 192 path = /path/to/foo.inc 193 194 ; include for all repositories inside /path/to/group 195 [includeIf "gitdir:/path/to/group/"] 196 path = /path/to/foo.inc 197 198 ; include for all repositories inside $HOME/to/group 199 [includeIf "gitdir:~/to/group/"] 200 path = /path/to/foo.inc 201 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/"] 206 path = foo.inc 207 208Values 209~~~~~~ 210 211Values of many variables are treated as a simple string, but there 212are variables that take values of specific types and there are rules 213as to how to spell them. 214 215boolean:: 216 217 When a variable is said to take a boolean value, many 218 synonyms are accepted for 'true' and 'false'; these are all 219 case-insensitive. 220 221 true;; Boolean true literals are `yes`, `on`, `true`, 222 and `1`. Also, a variable defined without `= <value>` 223 is taken as true. 224 225 false;; Boolean false literals are `no`, `off`, `false`, 226 `0` and the empty string. 227+ 228When converting a value to its canonical form using the `--type=bool` type 229specifier, 'git config' will ensure that the output is "true" or 230"false" (spelled in lowercase). 231 232integer:: 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. 236 237color:: 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. 241+ 242The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`, 243`blue`, `magenta`, `cyan` and `white`. The first color given is the 244foreground; the second is the background. 245+ 246Colors may also be given as numbers between 0 and 255; these use ANSI 247256-color mode (but note that not all terminals may support this). If 248your terminal supports it, you may also specify 24-bit RGB values as 249hex, like `#ff0ab3`. 250+ 251The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`, 252`italic`, and `strike` (for crossed-out or "strikethrough" letters). 253The position of any attributes with respect to the colors 254(before, after, or in between), doesn't matter. Specific attributes may 255be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`, 256`no-ul`, etc). 257+ 258An empty color string produces no color effect at all. This can be used 259to avoid coloring specific elements without disabling color entirely. 260+ 261For git's pre-defined color slots, the attributes are meant to be reset 262at the beginning of each item in the colored output. So setting 263`color.decorate.branch` to `black` will paint that branch name in a 264plain `black`, even if the previous thing on the same output line (e.g. 265opening parenthesis before the list of branch names in `log --decorate` 266output) is set to be painted with `bold` or some other attribute. 267However, custom log formats may do more complicated and layered 268coloring, and the negated forms may be useful there. 269 270pathname:: 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. 276 277 278Variables 279~~~~~~~~~ 280 281Note that this list is non-comprehensive and not necessarily complete. 282For command-specific variables, you will find a more detailed description 283in the appropriate manual page. 284 285Other git-related tools may and do use their own variables. When 286inventing new variables for use in your own tool, make sure their 287names do not conflict with those that are used by Git itself and 288other popular tools, and describe them in your documentation. 289 290include::config/advice.txt[] 291 292include::config/core.txt[] 293 294include::config/add.txt[] 295 296include::config/alias.txt[] 297 298include::config/am.txt[] 299 300include::config/apply.txt[] 301 302include::config/blame.txt[] 303 304include::config/branch.txt[] 305 306include::config/browser.txt[] 307 308include::config/checkout.txt[] 309 310include::config/clean.txt[] 311 312include::config/color.txt[] 313 314include::config/column.txt[] 315 316include::config/commit.txt[] 317 318include::config/credential.txt[] 319 320include::config/completion.txt[] 321 322include::config/diff.txt[] 323 324include::config/difftool.txt[] 325 326include::config/fastimport.txt[] 327 328include::config/fetch.txt[] 329 330include::config/format.txt[] 331 332include::config/filter.txt[] 333 334include::config/fsck.txt[] 335 336include::config/gc.txt[] 337 338include::config/gitcvs.txt[] 339 340include::config/gitweb.txt[] 341 342include::config/grep.txt[] 343 344include::config/gpg.txt[] 345 346include::config/gui.txt[] 347 348include::config/guitool.txt[] 349 350include::config/help.txt[] 351 352include::config/http.txt[] 353 354include::config/i18n.txt[] 355 356include::config/imap.txt[] 357 358include::config/index.txt[] 359 360include::config/init.txt[] 361 362include::config/instaweb.txt[] 363 364include::config/interactive.txt[] 365 366include::config/log.txt[] 367 368mailinfo.scissors:: 369 If true, makes linkgit:git-mailinfo[1] (and therefore 370 linkgit:git-am[1]) act by default as if the --scissors option 371 was provided on the command-line. When active, this features 372 removes everything from the message body before a scissors 373 line (i.e. consisting mainly of ">8", "8<" and "-"). 374 375mailmap.file:: 376 The location of an augmenting mailmap file. The default 377 mailmap, located in the root of the repository, is loaded 378 first, then the mailmap file pointed to by this variable. 379 The location of the mailmap file may be in a repository 380 subdirectory, or somewhere outside of the repository itself. 381 See linkgit:git-shortlog[1] and linkgit:git-blame[1]. 382 383mailmap.blob:: 384 Like `mailmap.file`, but consider the value as a reference to a 385 blob in the repository. If both `mailmap.file` and 386 `mailmap.blob` are given, both are parsed, with entries from 387 `mailmap.file` taking precedence. In a bare repository, this 388 defaults to `HEAD:.mailmap`. In a non-bare repository, it 389 defaults to empty. 390 391man.viewer:: 392 Specify the programs that may be used to display help in the 393 'man' format. See linkgit:git-help[1]. 394 395man.<tool>.cmd:: 396 Specify the command to invoke the specified man viewer. The 397 specified command is evaluated in shell with the man page 398 passed as argument. (See linkgit:git-help[1].) 399 400man.<tool>.path:: 401 Override the path for the given tool that may be used to 402 display help in the 'man' format. See linkgit:git-help[1]. 403 404include::merge-config.txt[] 405 406mergetool.<tool>.path:: 407 Override the path for the given tool. This is useful in case 408 your tool is not in the PATH. 409 410mergetool.<tool>.cmd:: 411 Specify the command to invoke the specified merge tool. The 412 specified command is evaluated in shell with the following 413 variables available: 'BASE' is the name of a temporary file 414 containing the common base of the files to be merged, if available; 415 'LOCAL' is the name of a temporary file containing the contents of 416 the file on the current branch; 'REMOTE' is the name of a temporary 417 file containing the contents of the file from the branch being 418 merged; 'MERGED' contains the name of the file to which the merge 419 tool should write the results of a successful merge. 420 421mergetool.<tool>.trustExitCode:: 422 For a custom merge command, specify whether the exit code of 423 the merge command can be used to determine whether the merge was 424 successful. If this is not set to true then the merge target file 425 timestamp is checked and the merge assumed to have been successful 426 if the file has been updated, otherwise the user is prompted to 427 indicate the success of the merge. 428 429mergetool.meld.hasOutput:: 430 Older versions of `meld` do not support the `--output` option. 431 Git will attempt to detect whether `meld` supports `--output` 432 by inspecting the output of `meld --help`. Configuring 433 `mergetool.meld.hasOutput` will make Git skip these checks and 434 use the configured value instead. Setting `mergetool.meld.hasOutput` 435 to `true` tells Git to unconditionally use the `--output` option, 436 and `false` avoids using `--output`. 437 438mergetool.keepBackup:: 439 After performing a merge, the original file with conflict markers 440 can be saved as a file with a `.orig` extension. If this variable 441 is set to `false` then this file is not preserved. Defaults to 442 `true` (i.e. keep the backup files). 443 444mergetool.keepTemporaries:: 445 When invoking a custom merge tool, Git uses a set of temporary 446 files to pass to the tool. If the tool returns an error and this 447 variable is set to `true`, then these temporary files will be 448 preserved, otherwise they will be removed after the tool has 449 exited. Defaults to `false`. 450 451mergetool.writeToTemp:: 452 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of 453 conflicting files in the worktree by default. Git will attempt 454 to use a temporary directory for these files when set `true`. 455 Defaults to `false`. 456 457mergetool.prompt:: 458 Prompt before each invocation of the merge resolution program. 459 460notes.mergeStrategy:: 461 Which merge strategy to choose by default when resolving notes 462 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or 463 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" 464 section of linkgit:git-notes[1] for more information on each strategy. 465 466notes.<name>.mergeStrategy:: 467 Which merge strategy to choose when doing a notes merge into 468 refs/notes/<name>. This overrides the more general 469 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in 470 linkgit:git-notes[1] for more information on the available strategies. 471 472notes.displayRef:: 473 The (fully qualified) refname from which to show notes when 474 showing commit messages. The value of this variable can be set 475 to a glob, in which case notes from all matching refs will be 476 shown. You may also specify this configuration variable 477 several times. A warning will be issued for refs that do not 478 exist, but a glob that does not match any refs is silently 479 ignored. 480+ 481This setting can be overridden with the `GIT_NOTES_DISPLAY_REF` 482environment variable, which must be a colon separated list of refs or 483globs. 484+ 485The effective value of "core.notesRef" (possibly overridden by 486GIT_NOTES_REF) is also implicitly added to the list of refs to be 487displayed. 488 489notes.rewrite.<command>:: 490 When rewriting commits with <command> (currently `amend` or 491 `rebase`) and this variable is set to `true`, Git 492 automatically copies your notes from the original to the 493 rewritten commit. Defaults to `true`, but see 494 "notes.rewriteRef" below. 495 496notes.rewriteMode:: 497 When copying notes during a rewrite (see the 498 "notes.rewrite.<command>" option), determines what to do if 499 the target commit already has a note. Must be one of 500 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. 501 Defaults to `concatenate`. 502+ 503This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` 504environment variable. 505 506notes.rewriteRef:: 507 When copying notes during a rewrite, specifies the (fully 508 qualified) ref whose notes should be copied. The ref may be a 509 glob, in which case notes in all matching refs will be copied. 510 You may also specify this configuration several times. 511+ 512Does not have a default value; you must configure this variable to 513enable note rewriting. Set it to `refs/notes/commits` to enable 514rewriting for the default commit notes. 515+ 516This setting can be overridden with the `GIT_NOTES_REWRITE_REF` 517environment variable, which must be a colon separated list of refs or 518globs. 519 520pack.window:: 521 The size of the window used by linkgit:git-pack-objects[1] when no 522 window size is given on the command line. Defaults to 10. 523 524pack.depth:: 525 The maximum delta depth used by linkgit:git-pack-objects[1] when no 526 maximum depth is given on the command line. Defaults to 50. 527 Maximum value is 4095. 528 529pack.windowMemory:: 530 The maximum size of memory that is consumed by each thread 531 in linkgit:git-pack-objects[1] for pack window memory when 532 no limit is given on the command line. The value can be 533 suffixed with "k", "m", or "g". When left unconfigured (or 534 set explicitly to 0), there will be no limit. 535 536pack.compression:: 537 An integer -1..9, indicating the compression level for objects 538 in a pack file. -1 is the zlib default. 0 means no 539 compression, and 1..9 are various speed/size tradeoffs, 9 being 540 slowest. If not set, defaults to core.compression. If that is 541 not set, defaults to -1, the zlib default, which is "a default 542 compromise between speed and compression (currently equivalent 543 to level 6)." 544+ 545Note that changing the compression level will not automatically recompress 546all existing objects. You can force recompression by passing the -F option 547to linkgit:git-repack[1]. 548 549pack.island:: 550 An extended regular expression configuring a set of delta 551 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] 552 for details. 553 554pack.islandCore:: 555 Specify an island name which gets to have its objects be 556 packed first. This creates a kind of pseudo-pack at the front 557 of one pack, so that the objects from the specified island are 558 hopefully faster to copy into any pack that should be served 559 to a user requesting these objects. In practice this means 560 that the island specified should likely correspond to what is 561 the most commonly cloned in the repo. See also "DELTA ISLANDS" 562 in linkgit:git-pack-objects[1]. 563 564pack.deltaCacheSize:: 565 The maximum memory in bytes used for caching deltas in 566 linkgit:git-pack-objects[1] before writing them out to a pack. 567 This cache is used to speed up the writing object phase by not 568 having to recompute the final delta result once the best match 569 for all objects is found. Repacking large repositories on machines 570 which are tight with memory might be badly impacted by this though, 571 especially if this cache pushes the system into swapping. 572 A value of 0 means no limit. The smallest size of 1 byte may be 573 used to virtually disable this cache. Defaults to 256 MiB. 574 575pack.deltaCacheLimit:: 576 The maximum size of a delta, that is cached in 577 linkgit:git-pack-objects[1]. This cache is used to speed up the 578 writing object phase by not having to recompute the final delta 579 result once the best match for all objects is found. 580 Defaults to 1000. Maximum value is 65535. 581 582pack.threads:: 583 Specifies the number of threads to spawn when searching for best 584 delta matches. This requires that linkgit:git-pack-objects[1] 585 be compiled with pthreads otherwise this option is ignored with a 586 warning. This is meant to reduce packing time on multiprocessor 587 machines. The required amount of memory for the delta search window 588 is however multiplied by the number of threads. 589 Specifying 0 will cause Git to auto-detect the number of CPU's 590 and set the number of threads accordingly. 591 592pack.indexVersion:: 593 Specify the default pack index version. Valid values are 1 for 594 legacy pack index used by Git versions prior to 1.5.2, and 2 for 595 the new pack index with capabilities for packs larger than 4 GB 596 as well as proper protection against the repacking of corrupted 597 packs. Version 2 is the default. Note that version 2 is enforced 598 and this config option ignored whenever the corresponding pack is 599 larger than 2 GB. 600+ 601If you have an old Git that does not understand the version 2 `*.idx` file, 602cloning or fetching over a non native protocol (e.g. "http") 603that will copy both `*.pack` file and corresponding `*.idx` file from the 604other side may give you a repository that cannot be accessed with your 605older version of Git. If the `*.pack` file is smaller than 2 GB, however, 606you can use linkgit:git-index-pack[1] on the *.pack file to regenerate 607the `*.idx` file. 608 609pack.packSizeLimit:: 610 The maximum size of a pack. This setting only affects 611 packing to a file when repacking, i.e. the git:// protocol 612 is unaffected. It can be overridden by the `--max-pack-size` 613 option of linkgit:git-repack[1]. Reaching this limit results 614 in the creation of multiple packfiles; which in turn prevents 615 bitmaps from being created. 616 The minimum size allowed is limited to 1 MiB. 617 The default is unlimited. 618 Common unit suffixes of 'k', 'm', or 'g' are 619 supported. 620 621pack.useBitmaps:: 622 When true, git will use pack bitmaps (if available) when packing 623 to stdout (e.g., during the server side of a fetch). Defaults to 624 true. You should not generally need to turn this off unless 625 you are debugging pack bitmaps. 626 627pack.writeBitmaps (deprecated):: 628 This is a deprecated synonym for `repack.writeBitmaps`. 629 630pack.writeBitmapHashCache:: 631 When true, git will include a "hash cache" section in the bitmap 632 index (if one is written). This cache can be used to feed git's 633 delta heuristics, potentially leading to better deltas between 634 bitmapped and non-bitmapped objects (e.g., when serving a fetch 635 between an older, bitmapped pack and objects that have been 636 pushed since the last gc). The downside is that it consumes 4 637 bytes per object of disk space, and that JGit's bitmap 638 implementation does not understand it, causing it to complain if 639 Git and JGit are used on the same repository. Defaults to false. 640 641pager.<cmd>:: 642 If the value is boolean, turns on or off pagination of the 643 output of a particular Git subcommand when writing to a tty. 644 Otherwise, turns on pagination for the subcommand using the 645 pager specified by the value of `pager.<cmd>`. If `--paginate` 646 or `--no-pager` is specified on the command line, it takes 647 precedence over this option. To disable pagination for all 648 commands, set `core.pager` or `GIT_PAGER` to `cat`. 649 650pretty.<name>:: 651 Alias for a --pretty= format string, as specified in 652 linkgit:git-log[1]. Any aliases defined here can be used just 653 as the built-in pretty formats could. For example, 654 running `git config pretty.changelog "format:* %H %s"` 655 would cause the invocation `git log --pretty=changelog` 656 to be equivalent to running `git log "--pretty=format:* %H %s"`. 657 Note that an alias with the same name as a built-in format 658 will be silently ignored. 659 660protocol.allow:: 661 If set, provide a user defined default policy for all protocols which 662 don't explicitly have a policy (`protocol.<name>.allow`). By default, 663 if unset, known-safe protocols (http, https, git, ssh, file) have a 664 default policy of `always`, known-dangerous protocols (ext) have a 665 default policy of `never`, and all other protocols have a default 666 policy of `user`. Supported policies: 667+ 668-- 669 670* `always` - protocol is always able to be used. 671 672* `never` - protocol is never able to be used. 673 674* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is 675 either unset or has a value of 1. This policy should be used when you want a 676 protocol to be directly usable by the user but don't want it used by commands which 677 execute clone/fetch/push commands without user input, e.g. recursive 678 submodule initialization. 679 680-- 681 682protocol.<name>.allow:: 683 Set a policy to be used by protocol `<name>` with clone/fetch/push 684 commands. See `protocol.allow` above for the available policies. 685+ 686The protocol names currently used by git are: 687+ 688-- 689 - `file`: any local file-based path (including `file://` URLs, 690 or local paths) 691 692 - `git`: the anonymous git protocol over a direct TCP 693 connection (or proxy, if configured) 694 695 - `ssh`: git over ssh (including `host:path` syntax, 696 `ssh://`, etc). 697 698 - `http`: git over http, both "smart http" and "dumb http". 699 Note that this does _not_ include `https`; if you want to configure 700 both, you must do so individually. 701 702 - any external helpers are named by their protocol (e.g., use 703 `hg` to allow the `git-remote-hg` helper) 704-- 705 706protocol.version:: 707 Experimental. If set, clients will attempt to communicate with a 708 server using the specified protocol version. If unset, no 709 attempt will be made by the client to communicate using a 710 particular protocol version, this results in protocol version 0 711 being used. 712 Supported versions: 713+ 714-- 715 716* `0` - the original wire protocol. 717 718* `1` - the original wire protocol with the addition of a version string 719 in the initial response from the server. 720 721* `2` - link:technical/protocol-v2.html[wire protocol version 2]. 722 723-- 724 725include::pull-config.txt[] 726 727include::push-config.txt[] 728 729include::rebase-config.txt[] 730 731include::receive-config.txt[] 732 733remote.pushDefault:: 734 The remote to push to by default. Overrides 735 `branch.<name>.remote` for all branches, and is overridden by 736 `branch.<name>.pushRemote` for specific branches. 737 738remote.<name>.url:: 739 The URL of a remote repository. See linkgit:git-fetch[1] or 740 linkgit:git-push[1]. 741 742remote.<name>.pushurl:: 743 The push URL of a remote repository. See linkgit:git-push[1]. 744 745remote.<name>.proxy:: 746 For remotes that require curl (http, https and ftp), the URL to 747 the proxy to use for that remote. Set to the empty string to 748 disable proxying for that remote. 749 750remote.<name>.proxyAuthMethod:: 751 For remotes that require curl (http, https and ftp), the method to use for 752 authenticating against the proxy in use (probably set in 753 `remote.<name>.proxy`). See `http.proxyAuthMethod`. 754 755remote.<name>.fetch:: 756 The default set of "refspec" for linkgit:git-fetch[1]. See 757 linkgit:git-fetch[1]. 758 759remote.<name>.push:: 760 The default set of "refspec" for linkgit:git-push[1]. See 761 linkgit:git-push[1]. 762 763remote.<name>.mirror:: 764 If true, pushing to this remote will automatically behave 765 as if the `--mirror` option was given on the command line. 766 767remote.<name>.skipDefaultUpdate:: 768 If true, this remote will be skipped by default when updating 769 using linkgit:git-fetch[1] or the `update` subcommand of 770 linkgit:git-remote[1]. 771 772remote.<name>.skipFetchAll:: 773 If true, this remote will be skipped by default when updating 774 using linkgit:git-fetch[1] or the `update` subcommand of 775 linkgit:git-remote[1]. 776 777remote.<name>.receivepack:: 778 The default program to execute on the remote side when pushing. See 779 option --receive-pack of linkgit:git-push[1]. 780 781remote.<name>.uploadpack:: 782 The default program to execute on the remote side when fetching. See 783 option --upload-pack of linkgit:git-fetch-pack[1]. 784 785remote.<name>.tagOpt:: 786 Setting this value to --no-tags disables automatic tag following when 787 fetching from remote <name>. Setting it to --tags will fetch every 788 tag from remote <name>, even if they are not reachable from remote 789 branch heads. Passing these flags directly to linkgit:git-fetch[1] can 790 override this setting. See options --tags and --no-tags of 791 linkgit:git-fetch[1]. 792 793remote.<name>.vcs:: 794 Setting this to a value <vcs> will cause Git to interact with 795 the remote with the git-remote-<vcs> helper. 796 797remote.<name>.prune:: 798 When set to true, fetching from this remote by default will also 799 remove any remote-tracking references that no longer exist on the 800 remote (as if the `--prune` option was given on the command line). 801 Overrides `fetch.prune` settings, if any. 802 803remote.<name>.pruneTags:: 804 When set to true, fetching from this remote by default will also 805 remove any local tags that no longer exist on the remote if pruning 806 is activated in general via `remote.<name>.prune`, `fetch.prune` or 807 `--prune`. Overrides `fetch.pruneTags` settings, if any. 808+ 809See also `remote.<name>.prune` and the PRUNING section of 810linkgit:git-fetch[1]. 811 812remotes.<group>:: 813 The list of remotes which are fetched by "git remote update 814 <group>". See linkgit:git-remote[1]. 815 816repack.useDeltaBaseOffset:: 817 By default, linkgit:git-repack[1] creates packs that use 818 delta-base offset. If you need to share your repository with 819 Git older than version 1.4.4, either directly or via a dumb 820 protocol such as http, then you need to set this option to 821 "false" and repack. Access from old Git versions over the 822 native protocol are unaffected by this option. 823 824repack.packKeptObjects:: 825 If set to true, makes `git repack` act as if 826 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for 827 details. Defaults to `false` normally, but `true` if a bitmap 828 index is being written (either via `--write-bitmap-index` or 829 `repack.writeBitmaps`). 830 831repack.useDeltaIslands:: 832 If set to true, makes `git repack` act as if `--delta-islands` 833 was passed. Defaults to `false`. 834 835repack.writeBitmaps:: 836 When true, git will write a bitmap index when packing all 837 objects to disk (e.g., when `git repack -a` is run). This 838 index can speed up the "counting objects" phase of subsequent 839 packs created for clones and fetches, at the cost of some disk 840 space and extra time spent on the initial repack. This has 841 no effect if multiple packfiles are created. 842 Defaults to false. 843 844rerere.autoUpdate:: 845 When set to true, `git-rerere` updates the index with the 846 resulting contents after it cleanly resolves conflicts using 847 previously recorded resolution. Defaults to false. 848 849rerere.enabled:: 850 Activate recording of resolved conflicts, so that identical 851 conflict hunks can be resolved automatically, should they be 852 encountered again. By default, linkgit:git-rerere[1] is 853 enabled if there is an `rr-cache` directory under the 854 `$GIT_DIR`, e.g. if "rerere" was previously used in the 855 repository. 856 857reset.quiet:: 858 When set to true, 'git reset' will default to the '--quiet' option. 859 860include::sendemail-config.txt[] 861 862sequence.editor:: 863 Text editor used by `git rebase -i` for editing the rebase instruction file. 864 The value is meant to be interpreted by the shell when it is used. 865 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. 866 When not configured the default commit message editor is used instead. 867 868showBranch.default:: 869 The default set of branches for linkgit:git-show-branch[1]. 870 See linkgit:git-show-branch[1]. 871 872splitIndex.maxPercentChange:: 873 When the split index feature is used, this specifies the 874 percent of entries the split index can contain compared to the 875 total number of entries in both the split index and the shared 876 index before a new shared index is written. 877 The value should be between 0 and 100. If the value is 0 then 878 a new shared index is always written, if it is 100 a new 879 shared index is never written. 880 By default the value is 20, so a new shared index is written 881 if the number of entries in the split index would be greater 882 than 20 percent of the total number of entries. 883 See linkgit:git-update-index[1]. 884 885splitIndex.sharedIndexExpire:: 886 When the split index feature is used, shared index files that 887 were not modified since the time this variable specifies will 888 be removed when a new shared index file is created. The value 889 "now" expires all entries immediately, and "never" suppresses 890 expiration altogether. 891 The default value is "2.weeks.ago". 892 Note that a shared index file is considered modified (for the 893 purpose of expiration) each time a new split-index file is 894 either created based on it or read from it. 895 See linkgit:git-update-index[1]. 896 897include::config/ssh.txt[] 898 899status.relativePaths:: 900 By default, linkgit:git-status[1] shows paths relative to the 901 current directory. Setting this variable to `false` shows paths 902 relative to the repository root (this was the default for Git 903 prior to v1.5.4). 904 905status.short:: 906 Set to true to enable --short by default in linkgit:git-status[1]. 907 The option --no-short takes precedence over this variable. 908 909status.branch:: 910 Set to true to enable --branch by default in linkgit:git-status[1]. 911 The option --no-branch takes precedence over this variable. 912 913status.displayCommentPrefix:: 914 If set to true, linkgit:git-status[1] will insert a comment 915 prefix before each output line (starting with 916 `core.commentChar`, i.e. `#` by default). This was the 917 behavior of linkgit:git-status[1] in Git 1.8.4 and previous. 918 Defaults to false. 919 920status.renameLimit:: 921 The number of files to consider when performing rename detection 922 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to 923 the value of diff.renameLimit. 924 925status.renames:: 926 Whether and how Git detects renames in linkgit:git-status[1] and 927 linkgit:git-commit[1] . If set to "false", rename detection is 928 disabled. If set to "true", basic rename detection is enabled. 929 If set to "copies" or "copy", Git will detect copies, as well. 930 Defaults to the value of diff.renames. 931 932status.showStash:: 933 If set to true, linkgit:git-status[1] will display the number of 934 entries currently stashed away. 935 Defaults to false. 936 937status.showUntrackedFiles:: 938 By default, linkgit:git-status[1] and linkgit:git-commit[1] show 939 files which are not currently tracked by Git. Directories which 940 contain only untracked files, are shown with the directory name 941 only. Showing untracked files means that Git needs to lstat() all 942 the files in the whole repository, which might be slow on some 943 systems. So, this variable controls how the commands displays 944 the untracked files. Possible values are: 945+ 946-- 947* `no` - Show no untracked files. 948* `normal` - Show untracked files and directories. 949* `all` - Show also individual files in untracked directories. 950-- 951+ 952If this variable is not specified, it defaults to 'normal'. 953This variable can be overridden with the -u|--untracked-files option 954of linkgit:git-status[1] and linkgit:git-commit[1]. 955 956status.submoduleSummary:: 957 Defaults to false. 958 If this is set to a non zero number or true (identical to -1 or an 959 unlimited number), the submodule summary will be enabled and a 960 summary of commits for modified submodules will be shown (see 961 --summary-limit option of linkgit:git-submodule[1]). Please note 962 that the summary output command will be suppressed for all 963 submodules when `diff.ignoreSubmodules` is set to 'all' or only 964 for those submodules where `submodule.<name>.ignore=all`. The only 965 exception to that rule is that status and commit will show staged 966 submodule changes. To 967 also view the summary for ignored submodules you can either use 968 the --ignore-submodules=dirty command-line option or the 'git 969 submodule summary' command, which shows a similar output but does 970 not honor these settings. 971 972stash.showPatch:: 973 If this is set to true, the `git stash show` command without an 974 option will show the stash entry in patch form. Defaults to false. 975 See description of 'show' command in linkgit:git-stash[1]. 976 977stash.showStat:: 978 If this is set to true, the `git stash show` command without an 979 option will show diffstat of the stash entry. Defaults to true. 980 See description of 'show' command in linkgit:git-stash[1]. 981 982include::submodule-config.txt[] 983 984tag.forceSignAnnotated:: 985 A boolean to specify whether annotated tags created should be GPG signed. 986 If `--annotate` is specified on the command line, it takes 987 precedence over this option. 988 989tag.sort:: 990 This variable controls the sort ordering of tags when displayed by 991 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the 992 value of this variable will be used as the default. 993 994tar.umask:: 995 This variable can be used to restrict the permission bits of 996 tar archive entries. The default is 0002, which turns off the 997 world write bit. The special value "user" indicates that the 998 archiving user's umask will be used instead. See umask(2) and 999 linkgit:git-archive[1].10001001transfer.fsckObjects::1002 When `fetch.fsckObjects` or `receive.fsckObjects` are1003 not set, the value of this variable is used instead.1004 Defaults to false.1005+1006When set, the fetch or receive will abort in the case of a malformed1007object or a link to a nonexistent object. In addition, various other1008issues are checked for, including legacy issues (see `fsck.<msg-id>`),1009and potential security issues like the existence of a `.GIT` directory1010or a malicious `.gitmodules` file (see the release notes for v2.2.11011and v2.17.1 for details). Other sanity and security checks may be1012added in future releases.1013+1014On the receiving side, failing fsckObjects will make those objects1015unreachable, see "QUARANTINE ENVIRONMENT" in1016linkgit:git-receive-pack[1]. On the fetch side, malformed objects will1017instead be left unreferenced in the repository.1018+1019Due to the non-quarantine nature of the `fetch.fsckObjects`1020implementation it can not be relied upon to leave the object store1021clean like `receive.fsckObjects` can.1022+1023As objects are unpacked they're written to the object store, so there1024can be cases where malicious objects get introduced even though the1025"fetch" failed, only to have a subsequent "fetch" succeed because only1026new incoming objects are checked, not those that have already been1027written to the object store. That difference in behavior should not be1028relied upon. In the future, such objects may be quarantined for1029"fetch" as well.1030+1031For now, the paranoid need to find some way to emulate the quarantine1032environment if they'd like the same protection as "push". E.g. in the1033case of an internal mirror do the mirroring in two steps, one to fetch1034the untrusted objects, and then do a second "push" (which will use the1035quarantine) to another internal repo, and have internal clients1036consume this pushed-to repository, or embargo internal fetches and1037only allow them once a full "fsck" has run (and no new fetches have1038happened in the meantime).10391040transfer.hideRefs::1041 String(s) `receive-pack` and `upload-pack` use to decide which1042 refs to omit from their initial advertisements. Use more than1043 one definition to specify multiple prefix strings. A ref that is1044 under the hierarchies listed in the value of this variable is1045 excluded, and is hidden when responding to `git push` or `git1046 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for1047 program-specific versions of this config.1048+1049You may also include a `!` in front of the ref name to negate the entry,1050explicitly exposing it, even if an earlier entry marked it as hidden.1051If you have multiple hideRefs values, later entries override earlier ones1052(and entries in more-specific config files override less-specific ones).1053+1054If a namespace is in use, the namespace prefix is stripped from each1055reference before it is matched against `transfer.hiderefs` patterns.1056For example, if `refs/heads/master` is specified in `transfer.hideRefs` and1057the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`1058is omitted from the advertisements but `refs/heads/master` and1059`refs/namespaces/bar/refs/heads/master` are still advertised as so-called1060"have" lines. In order to match refs before stripping, add a `^` in front of1061the ref name. If you combine `!` and `^`, `!` must be specified first.1062+1063Even if you hide refs, a client may still be able to steal the target1064objects via the techniques described in the "SECURITY" section of the1065linkgit:gitnamespaces[7] man page; it's best to keep private data in a1066separate repository.10671068transfer.unpackLimit::1069 When `fetch.unpackLimit` or `receive.unpackLimit` are1070 not set, the value of this variable is used instead.1071 The default value is 100.10721073uploadarchive.allowUnreachable::1074 If true, allow clients to use `git archive --remote` to request1075 any tree, whether reachable from the ref tips or not. See the1076 discussion in the "SECURITY" section of1077 linkgit:git-upload-archive[1] for more details. Defaults to1078 `false`.10791080uploadpack.hideRefs::1081 This variable is the same as `transfer.hideRefs`, but applies1082 only to `upload-pack` (and so affects only fetches, not pushes).1083 An attempt to fetch a hidden ref by `git fetch` will fail. See1084 also `uploadpack.allowTipSHA1InWant`.10851086uploadpack.allowTipSHA1InWant::1087 When `uploadpack.hideRefs` is in effect, allow `upload-pack`1088 to accept a fetch request that asks for an object at the tip1089 of a hidden ref (by default, such a request is rejected).1090 See also `uploadpack.hideRefs`. Even if this is false, a client1091 may be able to steal objects via the techniques described in the1092 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's1093 best to keep private data in a separate repository.10941095uploadpack.allowReachableSHA1InWant::1096 Allow `upload-pack` to accept a fetch request that asks for an1097 object that is reachable from any ref tip. However, note that1098 calculating object reachability is computationally expensive.1099 Defaults to `false`. Even if this is false, a client may be able1100 to steal objects via the techniques described in the "SECURITY"1101 section of the linkgit:gitnamespaces[7] man page; it's best to1102 keep private data in a separate repository.11031104uploadpack.allowAnySHA1InWant::1105 Allow `upload-pack` to accept a fetch request that asks for any1106 object at all.1107 Defaults to `false`.11081109uploadpack.keepAlive::1110 When `upload-pack` has started `pack-objects`, there may be a1111 quiet period while `pack-objects` prepares the pack. Normally1112 it would output progress information, but if `--quiet` was used1113 for the fetch, `pack-objects` will output nothing at all until1114 the pack data begins. Some clients and networks may consider1115 the server to be hung and give up. Setting this option instructs1116 `upload-pack` to send an empty keepalive packet every1117 `uploadpack.keepAlive` seconds. Setting this option to 01118 disables keepalive packets entirely. The default is 5 seconds.11191120uploadpack.packObjectsHook::1121 If this option is set, when `upload-pack` would run1122 `git pack-objects` to create a packfile for a client, it will1123 run this shell command instead. The `pack-objects` command and1124 arguments it _would_ have run (including the `git pack-objects`1125 at the beginning) are appended to the shell command. The stdin1126 and stdout of the hook are treated as if `pack-objects` itself1127 was run. I.e., `upload-pack` will feed input intended for1128 `pack-objects` to the hook, and expects a completed packfile on1129 stdout.1130+1131Note that this configuration variable is ignored if it is seen in the1132repository-level config (this is a safety measure against fetching from1133untrusted repositories).11341135uploadpack.allowFilter::1136 If this option is set, `upload-pack` will support partial1137 clone and partial fetch object filtering.11381139uploadpack.allowRefInWant::1140 If this option is set, `upload-pack` will support the `ref-in-want`1141 feature of the protocol version 2 `fetch` command. This feature1142 is intended for the benefit of load-balanced servers which may1143 not have the same view of what OIDs their refs point to due to1144 replication delay.11451146url.<base>.insteadOf::1147 Any URL that starts with this value will be rewritten to1148 start, instead, with <base>. In cases where some site serves a1149 large number of repositories, and serves them with multiple1150 access methods, and some users need to use different access1151 methods, this feature allows people to specify any of the1152 equivalent URLs and have Git automatically rewrite the URL to1153 the best alternative for the particular user, even for a1154 never-before-seen repository on the site. When more than one1155 insteadOf strings match a given URL, the longest match is used.1156+1157Note that any protocol restrictions will be applied to the rewritten1158URL. If the rewrite changes the URL to use a custom protocol or remote1159helper, you may need to adjust the `protocol.*.allow` config to permit1160the request. In particular, protocols you expect to use for submodules1161must be set to `always` rather than the default of `user`. See the1162description of `protocol.allow` above.11631164url.<base>.pushInsteadOf::1165 Any URL that starts with this value will not be pushed to;1166 instead, it will be rewritten to start with <base>, and the1167 resulting URL will be pushed to. In cases where some site serves1168 a large number of repositories, and serves them with multiple1169 access methods, some of which do not allow push, this feature1170 allows people to specify a pull-only URL and have Git1171 automatically use an appropriate URL to push, even for a1172 never-before-seen repository on the site. When more than one1173 pushInsteadOf strings match a given URL, the longest match is1174 used. If a remote has an explicit pushurl, Git will ignore this1175 setting for that remote.11761177user.email::1178 Your email address to be recorded in any newly created commits.1179 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and1180 `EMAIL` environment variables. See linkgit:git-commit-tree[1].11811182user.name::1183 Your full name to be recorded in any newly created commits.1184 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`1185 environment variables. See linkgit:git-commit-tree[1].11861187user.useConfigOnly::1188 Instruct Git to avoid trying to guess defaults for `user.email`1189 and `user.name`, and instead retrieve the values only from the1190 configuration. For example, if you have multiple email addresses1191 and would like to use a different one for each repository, then1192 with this configuration option set to `true` in the global config1193 along with a name, Git will prompt you to set up an email before1194 making new commits in a newly cloned repository.1195 Defaults to `false`.11961197user.signingKey::1198 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the1199 key you want it to automatically when creating a signed tag or1200 commit, you can override the default selection with this variable.1201 This option is passed unchanged to gpg's --local-user parameter,1202 so you may specify a key using any method that gpg supports.12031204versionsort.prereleaseSuffix (deprecated)::1205 Deprecated alias for `versionsort.suffix`. Ignored if1206 `versionsort.suffix` is set.12071208versionsort.suffix::1209 Even when version sort is used in linkgit:git-tag[1], tagnames1210 with the same base version but different suffixes are still sorted1211 lexicographically, resulting e.g. in prerelease tags appearing1212 after the main release (e.g. "1.0-rc1" after "1.0"). This1213 variable can be specified to determine the sorting order of tags1214 with different suffixes.1215+1216By specifying a single suffix in this variable, any tagname containing1217that suffix will appear before the corresponding main release. E.g. if1218the variable is set to "-rc", then all "1.0-rcX" tags will appear before1219"1.0". If specified multiple times, once per suffix, then the order of1220suffixes in the configuration will determine the sorting order of tagnames1221with those suffixes. E.g. if "-pre" appears before "-rc" in the1222configuration, then all "1.0-preX" tags will be listed before any1223"1.0-rcX" tags. The placement of the main release tag relative to tags1224with various suffixes can be determined by specifying the empty suffix1225among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and1226"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags1227are listed first, followed by "v4.8", then "v4.8-ckX" and finally1228"v4.8-bfsX".1229+1230If more than one suffixes match the same tagname, then that tagname will1231be sorted according to the suffix which starts at the earliest position in1232the tagname. If more than one different matching suffixes start at1233that earliest position, then that tagname will be sorted according to the1234longest of those suffixes.1235The sorting order between different suffixes is undefined if they are1236in multiple config files.12371238web.browser::1239 Specify a web browser that may be used by some commands.1240 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]1241 may use it.12421243worktree.guessRemote::1244 With `add`, if no branch argument, and neither of `-b` nor1245 `-B` nor `--detach` are given, the command defaults to1246 creating a new branch from HEAD. If `worktree.guessRemote` is1247 set to true, `worktree add` tries to find a remote-tracking1248 branch whose name uniquely matches the new branch name. If1249 such a branch exists, it is checked out and set as "upstream"1250 for the new branch. If no such match can be found, it falls1251 back to creating a new branch from the current HEAD.