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 368include::config/mailinfo.txt[] 369 370include::config/mailmap.txt[] 371 372include::config/man.txt[] 373 374include::config/merge.txt[] 375 376include::config/mergetool.txt[] 377 378include::config/notes.txt[] 379 380include::config/pack.txt[] 381 382include::config/pager.txt[] 383 384include::config/pretty.txt[] 385 386include::config/protocol.txt[] 387 388include::config/pull.txt[] 389 390include::config/push.txt[] 391 392include::config/rebase.txt[] 393 394include::config/receive.txt[] 395 396include::config/remote.txt[] 397 398include::config/remotes.txt[] 399 400repack.useDeltaBaseOffset:: 401 By default, linkgit:git-repack[1] creates packs that use 402 delta-base offset. If you need to share your repository with 403 Git older than version 1.4.4, either directly or via a dumb 404 protocol such as http, then you need to set this option to 405 "false" and repack. Access from old Git versions over the 406 native protocol are unaffected by this option. 407 408repack.packKeptObjects:: 409 If set to true, makes `git repack` act as if 410 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for 411 details. Defaults to `false` normally, but `true` if a bitmap 412 index is being written (either via `--write-bitmap-index` or 413 `repack.writeBitmaps`). 414 415repack.useDeltaIslands:: 416 If set to true, makes `git repack` act as if `--delta-islands` 417 was passed. Defaults to `false`. 418 419repack.writeBitmaps:: 420 When true, git will write a bitmap index when packing all 421 objects to disk (e.g., when `git repack -a` is run). This 422 index can speed up the "counting objects" phase of subsequent 423 packs created for clones and fetches, at the cost of some disk 424 space and extra time spent on the initial repack. This has 425 no effect if multiple packfiles are created. 426 Defaults to false. 427 428rerere.autoUpdate:: 429 When set to true, `git-rerere` updates the index with the 430 resulting contents after it cleanly resolves conflicts using 431 previously recorded resolution. Defaults to false. 432 433rerere.enabled:: 434 Activate recording of resolved conflicts, so that identical 435 conflict hunks can be resolved automatically, should they be 436 encountered again. By default, linkgit:git-rerere[1] is 437 enabled if there is an `rr-cache` directory under the 438 `$GIT_DIR`, e.g. if "rerere" was previously used in the 439 repository. 440 441reset.quiet:: 442 When set to true, 'git reset' will default to the '--quiet' option. 443 444include::sendemail-config.txt[] 445 446sequence.editor:: 447 Text editor used by `git rebase -i` for editing the rebase instruction file. 448 The value is meant to be interpreted by the shell when it is used. 449 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. 450 When not configured the default commit message editor is used instead. 451 452showBranch.default:: 453 The default set of branches for linkgit:git-show-branch[1]. 454 See linkgit:git-show-branch[1]. 455 456splitIndex.maxPercentChange:: 457 When the split index feature is used, this specifies the 458 percent of entries the split index can contain compared to the 459 total number of entries in both the split index and the shared 460 index before a new shared index is written. 461 The value should be between 0 and 100. If the value is 0 then 462 a new shared index is always written, if it is 100 a new 463 shared index is never written. 464 By default the value is 20, so a new shared index is written 465 if the number of entries in the split index would be greater 466 than 20 percent of the total number of entries. 467 See linkgit:git-update-index[1]. 468 469splitIndex.sharedIndexExpire:: 470 When the split index feature is used, shared index files that 471 were not modified since the time this variable specifies will 472 be removed when a new shared index file is created. The value 473 "now" expires all entries immediately, and "never" suppresses 474 expiration altogether. 475 The default value is "2.weeks.ago". 476 Note that a shared index file is considered modified (for the 477 purpose of expiration) each time a new split-index file is 478 either created based on it or read from it. 479 See linkgit:git-update-index[1]. 480 481include::config/ssh.txt[] 482 483status.relativePaths:: 484 By default, linkgit:git-status[1] shows paths relative to the 485 current directory. Setting this variable to `false` shows paths 486 relative to the repository root (this was the default for Git 487 prior to v1.5.4). 488 489status.short:: 490 Set to true to enable --short by default in linkgit:git-status[1]. 491 The option --no-short takes precedence over this variable. 492 493status.branch:: 494 Set to true to enable --branch by default in linkgit:git-status[1]. 495 The option --no-branch takes precedence over this variable. 496 497status.displayCommentPrefix:: 498 If set to true, linkgit:git-status[1] will insert a comment 499 prefix before each output line (starting with 500 `core.commentChar`, i.e. `#` by default). This was the 501 behavior of linkgit:git-status[1] in Git 1.8.4 and previous. 502 Defaults to false. 503 504status.renameLimit:: 505 The number of files to consider when performing rename detection 506 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to 507 the value of diff.renameLimit. 508 509status.renames:: 510 Whether and how Git detects renames in linkgit:git-status[1] and 511 linkgit:git-commit[1] . If set to "false", rename detection is 512 disabled. If set to "true", basic rename detection is enabled. 513 If set to "copies" or "copy", Git will detect copies, as well. 514 Defaults to the value of diff.renames. 515 516status.showStash:: 517 If set to true, linkgit:git-status[1] will display the number of 518 entries currently stashed away. 519 Defaults to false. 520 521status.showUntrackedFiles:: 522 By default, linkgit:git-status[1] and linkgit:git-commit[1] show 523 files which are not currently tracked by Git. Directories which 524 contain only untracked files, are shown with the directory name 525 only. Showing untracked files means that Git needs to lstat() all 526 the files in the whole repository, which might be slow on some 527 systems. So, this variable controls how the commands displays 528 the untracked files. Possible values are: 529+ 530-- 531* `no` - Show no untracked files. 532* `normal` - Show untracked files and directories. 533* `all` - Show also individual files in untracked directories. 534-- 535+ 536If this variable is not specified, it defaults to 'normal'. 537This variable can be overridden with the -u|--untracked-files option 538of linkgit:git-status[1] and linkgit:git-commit[1]. 539 540status.submoduleSummary:: 541 Defaults to false. 542 If this is set to a non zero number or true (identical to -1 or an 543 unlimited number), the submodule summary will be enabled and a 544 summary of commits for modified submodules will be shown (see 545 --summary-limit option of linkgit:git-submodule[1]). Please note 546 that the summary output command will be suppressed for all 547 submodules when `diff.ignoreSubmodules` is set to 'all' or only 548 for those submodules where `submodule.<name>.ignore=all`. The only 549 exception to that rule is that status and commit will show staged 550 submodule changes. To 551 also view the summary for ignored submodules you can either use 552 the --ignore-submodules=dirty command-line option or the 'git 553 submodule summary' command, which shows a similar output but does 554 not honor these settings. 555 556stash.showPatch:: 557 If this is set to true, the `git stash show` command without an 558 option will show the stash entry in patch form. Defaults to false. 559 See description of 'show' command in linkgit:git-stash[1]. 560 561stash.showStat:: 562 If this is set to true, the `git stash show` command without an 563 option will show diffstat of the stash entry. Defaults to true. 564 See description of 'show' command in linkgit:git-stash[1]. 565 566include::submodule-config.txt[] 567 568tag.forceSignAnnotated:: 569 A boolean to specify whether annotated tags created should be GPG signed. 570 If `--annotate` is specified on the command line, it takes 571 precedence over this option. 572 573tag.sort:: 574 This variable controls the sort ordering of tags when displayed by 575 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the 576 value of this variable will be used as the default. 577 578tar.umask:: 579 This variable can be used to restrict the permission bits of 580 tar archive entries. The default is 0002, which turns off the 581 world write bit. The special value "user" indicates that the 582 archiving user's umask will be used instead. See umask(2) and 583 linkgit:git-archive[1]. 584 585transfer.fsckObjects:: 586 When `fetch.fsckObjects` or `receive.fsckObjects` are 587 not set, the value of this variable is used instead. 588 Defaults to false. 589+ 590When set, the fetch or receive will abort in the case of a malformed 591object or a link to a nonexistent object. In addition, various other 592issues are checked for, including legacy issues (see `fsck.<msg-id>`), 593and potential security issues like the existence of a `.GIT` directory 594or a malicious `.gitmodules` file (see the release notes for v2.2.1 595and v2.17.1 for details). Other sanity and security checks may be 596added in future releases. 597+ 598On the receiving side, failing fsckObjects will make those objects 599unreachable, see "QUARANTINE ENVIRONMENT" in 600linkgit:git-receive-pack[1]. On the fetch side, malformed objects will 601instead be left unreferenced in the repository. 602+ 603Due to the non-quarantine nature of the `fetch.fsckObjects` 604implementation it can not be relied upon to leave the object store 605clean like `receive.fsckObjects` can. 606+ 607As objects are unpacked they're written to the object store, so there 608can be cases where malicious objects get introduced even though the 609"fetch" failed, only to have a subsequent "fetch" succeed because only 610new incoming objects are checked, not those that have already been 611written to the object store. That difference in behavior should not be 612relied upon. In the future, such objects may be quarantined for 613"fetch" as well. 614+ 615For now, the paranoid need to find some way to emulate the quarantine 616environment if they'd like the same protection as "push". E.g. in the 617case of an internal mirror do the mirroring in two steps, one to fetch 618the untrusted objects, and then do a second "push" (which will use the 619quarantine) to another internal repo, and have internal clients 620consume this pushed-to repository, or embargo internal fetches and 621only allow them once a full "fsck" has run (and no new fetches have 622happened in the meantime). 623 624transfer.hideRefs:: 625 String(s) `receive-pack` and `upload-pack` use to decide which 626 refs to omit from their initial advertisements. Use more than 627 one definition to specify multiple prefix strings. A ref that is 628 under the hierarchies listed in the value of this variable is 629 excluded, and is hidden when responding to `git push` or `git 630 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for 631 program-specific versions of this config. 632+ 633You may also include a `!` in front of the ref name to negate the entry, 634explicitly exposing it, even if an earlier entry marked it as hidden. 635If you have multiple hideRefs values, later entries override earlier ones 636(and entries in more-specific config files override less-specific ones). 637+ 638If a namespace is in use, the namespace prefix is stripped from each 639reference before it is matched against `transfer.hiderefs` patterns. 640For example, if `refs/heads/master` is specified in `transfer.hideRefs` and 641the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` 642is omitted from the advertisements but `refs/heads/master` and 643`refs/namespaces/bar/refs/heads/master` are still advertised as so-called 644"have" lines. In order to match refs before stripping, add a `^` in front of 645the ref name. If you combine `!` and `^`, `!` must be specified first. 646+ 647Even if you hide refs, a client may still be able to steal the target 648objects via the techniques described in the "SECURITY" section of the 649linkgit:gitnamespaces[7] man page; it's best to keep private data in a 650separate repository. 651 652transfer.unpackLimit:: 653 When `fetch.unpackLimit` or `receive.unpackLimit` are 654 not set, the value of this variable is used instead. 655 The default value is 100. 656 657uploadarchive.allowUnreachable:: 658 If true, allow clients to use `git archive --remote` to request 659 any tree, whether reachable from the ref tips or not. See the 660 discussion in the "SECURITY" section of 661 linkgit:git-upload-archive[1] for more details. Defaults to 662 `false`. 663 664uploadpack.hideRefs:: 665 This variable is the same as `transfer.hideRefs`, but applies 666 only to `upload-pack` (and so affects only fetches, not pushes). 667 An attempt to fetch a hidden ref by `git fetch` will fail. See 668 also `uploadpack.allowTipSHA1InWant`. 669 670uploadpack.allowTipSHA1InWant:: 671 When `uploadpack.hideRefs` is in effect, allow `upload-pack` 672 to accept a fetch request that asks for an object at the tip 673 of a hidden ref (by default, such a request is rejected). 674 See also `uploadpack.hideRefs`. Even if this is false, a client 675 may be able to steal objects via the techniques described in the 676 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's 677 best to keep private data in a separate repository. 678 679uploadpack.allowReachableSHA1InWant:: 680 Allow `upload-pack` to accept a fetch request that asks for an 681 object that is reachable from any ref tip. However, note that 682 calculating object reachability is computationally expensive. 683 Defaults to `false`. Even if this is false, a client may be able 684 to steal objects via the techniques described in the "SECURITY" 685 section of the linkgit:gitnamespaces[7] man page; it's best to 686 keep private data in a separate repository. 687 688uploadpack.allowAnySHA1InWant:: 689 Allow `upload-pack` to accept a fetch request that asks for any 690 object at all. 691 Defaults to `false`. 692 693uploadpack.keepAlive:: 694 When `upload-pack` has started `pack-objects`, there may be a 695 quiet period while `pack-objects` prepares the pack. Normally 696 it would output progress information, but if `--quiet` was used 697 for the fetch, `pack-objects` will output nothing at all until 698 the pack data begins. Some clients and networks may consider 699 the server to be hung and give up. Setting this option instructs 700 `upload-pack` to send an empty keepalive packet every 701 `uploadpack.keepAlive` seconds. Setting this option to 0 702 disables keepalive packets entirely. The default is 5 seconds. 703 704uploadpack.packObjectsHook:: 705 If this option is set, when `upload-pack` would run 706 `git pack-objects` to create a packfile for a client, it will 707 run this shell command instead. The `pack-objects` command and 708 arguments it _would_ have run (including the `git pack-objects` 709 at the beginning) are appended to the shell command. The stdin 710 and stdout of the hook are treated as if `pack-objects` itself 711 was run. I.e., `upload-pack` will feed input intended for 712 `pack-objects` to the hook, and expects a completed packfile on 713 stdout. 714+ 715Note that this configuration variable is ignored if it is seen in the 716repository-level config (this is a safety measure against fetching from 717untrusted repositories). 718 719uploadpack.allowFilter:: 720 If this option is set, `upload-pack` will support partial 721 clone and partial fetch object filtering. 722 723uploadpack.allowRefInWant:: 724 If this option is set, `upload-pack` will support the `ref-in-want` 725 feature of the protocol version 2 `fetch` command. This feature 726 is intended for the benefit of load-balanced servers which may 727 not have the same view of what OIDs their refs point to due to 728 replication delay. 729 730url.<base>.insteadOf:: 731 Any URL that starts with this value will be rewritten to 732 start, instead, with <base>. In cases where some site serves a 733 large number of repositories, and serves them with multiple 734 access methods, and some users need to use different access 735 methods, this feature allows people to specify any of the 736 equivalent URLs and have Git automatically rewrite the URL to 737 the best alternative for the particular user, even for a 738 never-before-seen repository on the site. When more than one 739 insteadOf strings match a given URL, the longest match is used. 740+ 741Note that any protocol restrictions will be applied to the rewritten 742URL. If the rewrite changes the URL to use a custom protocol or remote 743helper, you may need to adjust the `protocol.*.allow` config to permit 744the request. In particular, protocols you expect to use for submodules 745must be set to `always` rather than the default of `user`. See the 746description of `protocol.allow` above. 747 748url.<base>.pushInsteadOf:: 749 Any URL that starts with this value will not be pushed to; 750 instead, it will be rewritten to start with <base>, and the 751 resulting URL will be pushed to. In cases where some site serves 752 a large number of repositories, and serves them with multiple 753 access methods, some of which do not allow push, this feature 754 allows people to specify a pull-only URL and have Git 755 automatically use an appropriate URL to push, even for a 756 never-before-seen repository on the site. When more than one 757 pushInsteadOf strings match a given URL, the longest match is 758 used. If a remote has an explicit pushurl, Git will ignore this 759 setting for that remote. 760 761user.email:: 762 Your email address to be recorded in any newly created commits. 763 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and 764 `EMAIL` environment variables. See linkgit:git-commit-tree[1]. 765 766user.name:: 767 Your full name to be recorded in any newly created commits. 768 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME` 769 environment variables. See linkgit:git-commit-tree[1]. 770 771user.useConfigOnly:: 772 Instruct Git to avoid trying to guess defaults for `user.email` 773 and `user.name`, and instead retrieve the values only from the 774 configuration. For example, if you have multiple email addresses 775 and would like to use a different one for each repository, then 776 with this configuration option set to `true` in the global config 777 along with a name, Git will prompt you to set up an email before 778 making new commits in a newly cloned repository. 779 Defaults to `false`. 780 781user.signingKey:: 782 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the 783 key you want it to automatically when creating a signed tag or 784 commit, you can override the default selection with this variable. 785 This option is passed unchanged to gpg's --local-user parameter, 786 so you may specify a key using any method that gpg supports. 787 788versionsort.prereleaseSuffix (deprecated):: 789 Deprecated alias for `versionsort.suffix`. Ignored if 790 `versionsort.suffix` is set. 791 792versionsort.suffix:: 793 Even when version sort is used in linkgit:git-tag[1], tagnames 794 with the same base version but different suffixes are still sorted 795 lexicographically, resulting e.g. in prerelease tags appearing 796 after the main release (e.g. "1.0-rc1" after "1.0"). This 797 variable can be specified to determine the sorting order of tags 798 with different suffixes. 799+ 800By specifying a single suffix in this variable, any tagname containing 801that suffix will appear before the corresponding main release. E.g. if 802the variable is set to "-rc", then all "1.0-rcX" tags will appear before 803"1.0". If specified multiple times, once per suffix, then the order of 804suffixes in the configuration will determine the sorting order of tagnames 805with those suffixes. E.g. if "-pre" appears before "-rc" in the 806configuration, then all "1.0-preX" tags will be listed before any 807"1.0-rcX" tags. The placement of the main release tag relative to tags 808with various suffixes can be determined by specifying the empty suffix 809among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and 810"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags 811are listed first, followed by "v4.8", then "v4.8-ckX" and finally 812"v4.8-bfsX". 813+ 814If more than one suffixes match the same tagname, then that tagname will 815be sorted according to the suffix which starts at the earliest position in 816the tagname. If more than one different matching suffixes start at 817that earliest position, then that tagname will be sorted according to the 818longest of those suffixes. 819The sorting order between different suffixes is undefined if they are 820in multiple config files. 821 822web.browser:: 823 Specify a web browser that may be used by some commands. 824 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1] 825 may use it. 826 827worktree.guessRemote:: 828 With `add`, if no branch argument, and neither of `-b` nor 829 `-B` nor `--detach` are given, the command defaults to 830 creating a new branch from HEAD. If `worktree.guessRemote` is 831 set to true, `worktree add` tries to find a remote-tracking 832 branch whose name uniquely matches the new branch name. If 833 such a branch exists, it is checked out and set as "upstream" 834 for the new branch. If no such match can be found, it falls 835 back to creating a new branch from the current HEAD.