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 356imap:: 357 The configuration variables in the 'imap' section are described 358 in linkgit:git-imap-send[1]. 359 360index.threads:: 361 Specifies the number of threads to spawn when loading the index. 362 This is meant to reduce index load time on multiprocessor machines. 363 Specifying 0 or 'true' will cause Git to auto-detect the number of 364 CPU's and set the number of threads accordingly. Specifying 1 or 365 'false' will disable multithreading. Defaults to 'true'. 366 367index.version:: 368 Specify the version with which new index files should be 369 initialized. This does not affect existing repositories. 370 371init.templateDir:: 372 Specify the directory from which templates will be copied. 373 (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) 374 375instaweb.browser:: 376 Specify the program that will be used to browse your working 377 repository in gitweb. See linkgit:git-instaweb[1]. 378 379instaweb.httpd:: 380 The HTTP daemon command-line to start gitweb on your working 381 repository. See linkgit:git-instaweb[1]. 382 383instaweb.local:: 384 If true the web server started by linkgit:git-instaweb[1] will 385 be bound to the local IP (127.0.0.1). 386 387instaweb.modulePath:: 388 The default module path for linkgit:git-instaweb[1] to use 389 instead of /usr/lib/apache2/modules. Only used if httpd 390 is Apache. 391 392instaweb.port:: 393 The port number to bind the gitweb httpd to. See 394 linkgit:git-instaweb[1]. 395 396interactive.singleKey:: 397 In interactive commands, allow the user to provide one-letter 398 input with a single key (i.e., without hitting enter). 399 Currently this is used by the `--patch` mode of 400 linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1], 401 linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this 402 setting is silently ignored if portable keystroke input 403 is not available; requires the Perl module Term::ReadKey. 404 405interactive.diffFilter:: 406 When an interactive command (such as `git add --patch`) shows 407 a colorized diff, git will pipe the diff through the shell 408 command defined by this configuration variable. The command may 409 mark up the diff further for human consumption, provided that it 410 retains a one-to-one correspondence with the lines in the 411 original diff. Defaults to disabled (no filtering). 412 413log.abbrevCommit:: 414 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 415 linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may 416 override this option with `--no-abbrev-commit`. 417 418log.date:: 419 Set the default date-time mode for the 'log' command. 420 Setting a value for log.date is similar to using 'git log''s 421 `--date` option. See linkgit:git-log[1] for details. 422 423log.decorate:: 424 Print out the ref names of any commits that are shown by the log 425 command. If 'short' is specified, the ref name prefixes 'refs/heads/', 426 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is 427 specified, the full ref name (including prefix) will be printed. 428 If 'auto' is specified, then if the output is going to a terminal, 429 the ref names are shown as if 'short' were given, otherwise no ref 430 names are shown. This is the same as the `--decorate` option 431 of the `git log`. 432 433log.follow:: 434 If `true`, `git log` will act as if the `--follow` option was used when 435 a single <path> is given. This has the same limitations as `--follow`, 436 i.e. it cannot be used to follow multiple files and does not work well 437 on non-linear history. 438 439log.graphColors:: 440 A list of colors, separated by commas, that can be used to draw 441 history lines in `git log --graph`. 442 443log.showRoot:: 444 If true, the initial commit will be shown as a big creation event. 445 This is equivalent to a diff against an empty tree. 446 Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which 447 normally hide the root commit will now show it. True by default. 448 449log.showSignature:: 450 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 451 linkgit:git-whatchanged[1] assume `--show-signature`. 452 453log.mailmap:: 454 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 455 linkgit:git-whatchanged[1] assume `--use-mailmap`. 456 457mailinfo.scissors:: 458 If true, makes linkgit:git-mailinfo[1] (and therefore 459 linkgit:git-am[1]) act by default as if the --scissors option 460 was provided on the command-line. When active, this features 461 removes everything from the message body before a scissors 462 line (i.e. consisting mainly of ">8", "8<" and "-"). 463 464mailmap.file:: 465 The location of an augmenting mailmap file. The default 466 mailmap, located in the root of the repository, is loaded 467 first, then the mailmap file pointed to by this variable. 468 The location of the mailmap file may be in a repository 469 subdirectory, or somewhere outside of the repository itself. 470 See linkgit:git-shortlog[1] and linkgit:git-blame[1]. 471 472mailmap.blob:: 473 Like `mailmap.file`, but consider the value as a reference to a 474 blob in the repository. If both `mailmap.file` and 475 `mailmap.blob` are given, both are parsed, with entries from 476 `mailmap.file` taking precedence. In a bare repository, this 477 defaults to `HEAD:.mailmap`. In a non-bare repository, it 478 defaults to empty. 479 480man.viewer:: 481 Specify the programs that may be used to display help in the 482 'man' format. See linkgit:git-help[1]. 483 484man.<tool>.cmd:: 485 Specify the command to invoke the specified man viewer. The 486 specified command is evaluated in shell with the man page 487 passed as argument. (See linkgit:git-help[1].) 488 489man.<tool>.path:: 490 Override the path for the given tool that may be used to 491 display help in the 'man' format. See linkgit:git-help[1]. 492 493include::merge-config.txt[] 494 495mergetool.<tool>.path:: 496 Override the path for the given tool. This is useful in case 497 your tool is not in the PATH. 498 499mergetool.<tool>.cmd:: 500 Specify the command to invoke the specified merge tool. The 501 specified command is evaluated in shell with the following 502 variables available: 'BASE' is the name of a temporary file 503 containing the common base of the files to be merged, if available; 504 'LOCAL' is the name of a temporary file containing the contents of 505 the file on the current branch; 'REMOTE' is the name of a temporary 506 file containing the contents of the file from the branch being 507 merged; 'MERGED' contains the name of the file to which the merge 508 tool should write the results of a successful merge. 509 510mergetool.<tool>.trustExitCode:: 511 For a custom merge command, specify whether the exit code of 512 the merge command can be used to determine whether the merge was 513 successful. If this is not set to true then the merge target file 514 timestamp is checked and the merge assumed to have been successful 515 if the file has been updated, otherwise the user is prompted to 516 indicate the success of the merge. 517 518mergetool.meld.hasOutput:: 519 Older versions of `meld` do not support the `--output` option. 520 Git will attempt to detect whether `meld` supports `--output` 521 by inspecting the output of `meld --help`. Configuring 522 `mergetool.meld.hasOutput` will make Git skip these checks and 523 use the configured value instead. Setting `mergetool.meld.hasOutput` 524 to `true` tells Git to unconditionally use the `--output` option, 525 and `false` avoids using `--output`. 526 527mergetool.keepBackup:: 528 After performing a merge, the original file with conflict markers 529 can be saved as a file with a `.orig` extension. If this variable 530 is set to `false` then this file is not preserved. Defaults to 531 `true` (i.e. keep the backup files). 532 533mergetool.keepTemporaries:: 534 When invoking a custom merge tool, Git uses a set of temporary 535 files to pass to the tool. If the tool returns an error and this 536 variable is set to `true`, then these temporary files will be 537 preserved, otherwise they will be removed after the tool has 538 exited. Defaults to `false`. 539 540mergetool.writeToTemp:: 541 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of 542 conflicting files in the worktree by default. Git will attempt 543 to use a temporary directory for these files when set `true`. 544 Defaults to `false`. 545 546mergetool.prompt:: 547 Prompt before each invocation of the merge resolution program. 548 549notes.mergeStrategy:: 550 Which merge strategy to choose by default when resolving notes 551 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or 552 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" 553 section of linkgit:git-notes[1] for more information on each strategy. 554 555notes.<name>.mergeStrategy:: 556 Which merge strategy to choose when doing a notes merge into 557 refs/notes/<name>. This overrides the more general 558 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in 559 linkgit:git-notes[1] for more information on the available strategies. 560 561notes.displayRef:: 562 The (fully qualified) refname from which to show notes when 563 showing commit messages. The value of this variable can be set 564 to a glob, in which case notes from all matching refs will be 565 shown. You may also specify this configuration variable 566 several times. A warning will be issued for refs that do not 567 exist, but a glob that does not match any refs is silently 568 ignored. 569+ 570This setting can be overridden with the `GIT_NOTES_DISPLAY_REF` 571environment variable, which must be a colon separated list of refs or 572globs. 573+ 574The effective value of "core.notesRef" (possibly overridden by 575GIT_NOTES_REF) is also implicitly added to the list of refs to be 576displayed. 577 578notes.rewrite.<command>:: 579 When rewriting commits with <command> (currently `amend` or 580 `rebase`) and this variable is set to `true`, Git 581 automatically copies your notes from the original to the 582 rewritten commit. Defaults to `true`, but see 583 "notes.rewriteRef" below. 584 585notes.rewriteMode:: 586 When copying notes during a rewrite (see the 587 "notes.rewrite.<command>" option), determines what to do if 588 the target commit already has a note. Must be one of 589 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. 590 Defaults to `concatenate`. 591+ 592This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` 593environment variable. 594 595notes.rewriteRef:: 596 When copying notes during a rewrite, specifies the (fully 597 qualified) ref whose notes should be copied. The ref may be a 598 glob, in which case notes in all matching refs will be copied. 599 You may also specify this configuration several times. 600+ 601Does not have a default value; you must configure this variable to 602enable note rewriting. Set it to `refs/notes/commits` to enable 603rewriting for the default commit notes. 604+ 605This setting can be overridden with the `GIT_NOTES_REWRITE_REF` 606environment variable, which must be a colon separated list of refs or 607globs. 608 609pack.window:: 610 The size of the window used by linkgit:git-pack-objects[1] when no 611 window size is given on the command line. Defaults to 10. 612 613pack.depth:: 614 The maximum delta depth used by linkgit:git-pack-objects[1] when no 615 maximum depth is given on the command line. Defaults to 50. 616 Maximum value is 4095. 617 618pack.windowMemory:: 619 The maximum size of memory that is consumed by each thread 620 in linkgit:git-pack-objects[1] for pack window memory when 621 no limit is given on the command line. The value can be 622 suffixed with "k", "m", or "g". When left unconfigured (or 623 set explicitly to 0), there will be no limit. 624 625pack.compression:: 626 An integer -1..9, indicating the compression level for objects 627 in a pack file. -1 is the zlib default. 0 means no 628 compression, and 1..9 are various speed/size tradeoffs, 9 being 629 slowest. If not set, defaults to core.compression. If that is 630 not set, defaults to -1, the zlib default, which is "a default 631 compromise between speed and compression (currently equivalent 632 to level 6)." 633+ 634Note that changing the compression level will not automatically recompress 635all existing objects. You can force recompression by passing the -F option 636to linkgit:git-repack[1]. 637 638pack.island:: 639 An extended regular expression configuring a set of delta 640 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] 641 for details. 642 643pack.islandCore:: 644 Specify an island name which gets to have its objects be 645 packed first. This creates a kind of pseudo-pack at the front 646 of one pack, so that the objects from the specified island are 647 hopefully faster to copy into any pack that should be served 648 to a user requesting these objects. In practice this means 649 that the island specified should likely correspond to what is 650 the most commonly cloned in the repo. See also "DELTA ISLANDS" 651 in linkgit:git-pack-objects[1]. 652 653pack.deltaCacheSize:: 654 The maximum memory in bytes used for caching deltas in 655 linkgit:git-pack-objects[1] before writing them out to a pack. 656 This cache is used to speed up the writing object phase by not 657 having to recompute the final delta result once the best match 658 for all objects is found. Repacking large repositories on machines 659 which are tight with memory might be badly impacted by this though, 660 especially if this cache pushes the system into swapping. 661 A value of 0 means no limit. The smallest size of 1 byte may be 662 used to virtually disable this cache. Defaults to 256 MiB. 663 664pack.deltaCacheLimit:: 665 The maximum size of a delta, that is cached in 666 linkgit:git-pack-objects[1]. This cache is used to speed up the 667 writing object phase by not having to recompute the final delta 668 result once the best match for all objects is found. 669 Defaults to 1000. Maximum value is 65535. 670 671pack.threads:: 672 Specifies the number of threads to spawn when searching for best 673 delta matches. This requires that linkgit:git-pack-objects[1] 674 be compiled with pthreads otherwise this option is ignored with a 675 warning. This is meant to reduce packing time on multiprocessor 676 machines. The required amount of memory for the delta search window 677 is however multiplied by the number of threads. 678 Specifying 0 will cause Git to auto-detect the number of CPU's 679 and set the number of threads accordingly. 680 681pack.indexVersion:: 682 Specify the default pack index version. Valid values are 1 for 683 legacy pack index used by Git versions prior to 1.5.2, and 2 for 684 the new pack index with capabilities for packs larger than 4 GB 685 as well as proper protection against the repacking of corrupted 686 packs. Version 2 is the default. Note that version 2 is enforced 687 and this config option ignored whenever the corresponding pack is 688 larger than 2 GB. 689+ 690If you have an old Git that does not understand the version 2 `*.idx` file, 691cloning or fetching over a non native protocol (e.g. "http") 692that will copy both `*.pack` file and corresponding `*.idx` file from the 693other side may give you a repository that cannot be accessed with your 694older version of Git. If the `*.pack` file is smaller than 2 GB, however, 695you can use linkgit:git-index-pack[1] on the *.pack file to regenerate 696the `*.idx` file. 697 698pack.packSizeLimit:: 699 The maximum size of a pack. This setting only affects 700 packing to a file when repacking, i.e. the git:// protocol 701 is unaffected. It can be overridden by the `--max-pack-size` 702 option of linkgit:git-repack[1]. Reaching this limit results 703 in the creation of multiple packfiles; which in turn prevents 704 bitmaps from being created. 705 The minimum size allowed is limited to 1 MiB. 706 The default is unlimited. 707 Common unit suffixes of 'k', 'm', or 'g' are 708 supported. 709 710pack.useBitmaps:: 711 When true, git will use pack bitmaps (if available) when packing 712 to stdout (e.g., during the server side of a fetch). Defaults to 713 true. You should not generally need to turn this off unless 714 you are debugging pack bitmaps. 715 716pack.writeBitmaps (deprecated):: 717 This is a deprecated synonym for `repack.writeBitmaps`. 718 719pack.writeBitmapHashCache:: 720 When true, git will include a "hash cache" section in the bitmap 721 index (if one is written). This cache can be used to feed git's 722 delta heuristics, potentially leading to better deltas between 723 bitmapped and non-bitmapped objects (e.g., when serving a fetch 724 between an older, bitmapped pack and objects that have been 725 pushed since the last gc). The downside is that it consumes 4 726 bytes per object of disk space, and that JGit's bitmap 727 implementation does not understand it, causing it to complain if 728 Git and JGit are used on the same repository. Defaults to false. 729 730pager.<cmd>:: 731 If the value is boolean, turns on or off pagination of the 732 output of a particular Git subcommand when writing to a tty. 733 Otherwise, turns on pagination for the subcommand using the 734 pager specified by the value of `pager.<cmd>`. If `--paginate` 735 or `--no-pager` is specified on the command line, it takes 736 precedence over this option. To disable pagination for all 737 commands, set `core.pager` or `GIT_PAGER` to `cat`. 738 739pretty.<name>:: 740 Alias for a --pretty= format string, as specified in 741 linkgit:git-log[1]. Any aliases defined here can be used just 742 as the built-in pretty formats could. For example, 743 running `git config pretty.changelog "format:* %H %s"` 744 would cause the invocation `git log --pretty=changelog` 745 to be equivalent to running `git log "--pretty=format:* %H %s"`. 746 Note that an alias with the same name as a built-in format 747 will be silently ignored. 748 749protocol.allow:: 750 If set, provide a user defined default policy for all protocols which 751 don't explicitly have a policy (`protocol.<name>.allow`). By default, 752 if unset, known-safe protocols (http, https, git, ssh, file) have a 753 default policy of `always`, known-dangerous protocols (ext) have a 754 default policy of `never`, and all other protocols have a default 755 policy of `user`. Supported policies: 756+ 757-- 758 759* `always` - protocol is always able to be used. 760 761* `never` - protocol is never able to be used. 762 763* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is 764 either unset or has a value of 1. This policy should be used when you want a 765 protocol to be directly usable by the user but don't want it used by commands which 766 execute clone/fetch/push commands without user input, e.g. recursive 767 submodule initialization. 768 769-- 770 771protocol.<name>.allow:: 772 Set a policy to be used by protocol `<name>` with clone/fetch/push 773 commands. See `protocol.allow` above for the available policies. 774+ 775The protocol names currently used by git are: 776+ 777-- 778 - `file`: any local file-based path (including `file://` URLs, 779 or local paths) 780 781 - `git`: the anonymous git protocol over a direct TCP 782 connection (or proxy, if configured) 783 784 - `ssh`: git over ssh (including `host:path` syntax, 785 `ssh://`, etc). 786 787 - `http`: git over http, both "smart http" and "dumb http". 788 Note that this does _not_ include `https`; if you want to configure 789 both, you must do so individually. 790 791 - any external helpers are named by their protocol (e.g., use 792 `hg` to allow the `git-remote-hg` helper) 793-- 794 795protocol.version:: 796 Experimental. If set, clients will attempt to communicate with a 797 server using the specified protocol version. If unset, no 798 attempt will be made by the client to communicate using a 799 particular protocol version, this results in protocol version 0 800 being used. 801 Supported versions: 802+ 803-- 804 805* `0` - the original wire protocol. 806 807* `1` - the original wire protocol with the addition of a version string 808 in the initial response from the server. 809 810* `2` - link:technical/protocol-v2.html[wire protocol version 2]. 811 812-- 813 814include::pull-config.txt[] 815 816include::push-config.txt[] 817 818include::rebase-config.txt[] 819 820include::receive-config.txt[] 821 822remote.pushDefault:: 823 The remote to push to by default. Overrides 824 `branch.<name>.remote` for all branches, and is overridden by 825 `branch.<name>.pushRemote` for specific branches. 826 827remote.<name>.url:: 828 The URL of a remote repository. See linkgit:git-fetch[1] or 829 linkgit:git-push[1]. 830 831remote.<name>.pushurl:: 832 The push URL of a remote repository. See linkgit:git-push[1]. 833 834remote.<name>.proxy:: 835 For remotes that require curl (http, https and ftp), the URL to 836 the proxy to use for that remote. Set to the empty string to 837 disable proxying for that remote. 838 839remote.<name>.proxyAuthMethod:: 840 For remotes that require curl (http, https and ftp), the method to use for 841 authenticating against the proxy in use (probably set in 842 `remote.<name>.proxy`). See `http.proxyAuthMethod`. 843 844remote.<name>.fetch:: 845 The default set of "refspec" for linkgit:git-fetch[1]. See 846 linkgit:git-fetch[1]. 847 848remote.<name>.push:: 849 The default set of "refspec" for linkgit:git-push[1]. See 850 linkgit:git-push[1]. 851 852remote.<name>.mirror:: 853 If true, pushing to this remote will automatically behave 854 as if the `--mirror` option was given on the command line. 855 856remote.<name>.skipDefaultUpdate:: 857 If true, this remote will be skipped by default when updating 858 using linkgit:git-fetch[1] or the `update` subcommand of 859 linkgit:git-remote[1]. 860 861remote.<name>.skipFetchAll:: 862 If true, this remote will be skipped by default when updating 863 using linkgit:git-fetch[1] or the `update` subcommand of 864 linkgit:git-remote[1]. 865 866remote.<name>.receivepack:: 867 The default program to execute on the remote side when pushing. See 868 option --receive-pack of linkgit:git-push[1]. 869 870remote.<name>.uploadpack:: 871 The default program to execute on the remote side when fetching. See 872 option --upload-pack of linkgit:git-fetch-pack[1]. 873 874remote.<name>.tagOpt:: 875 Setting this value to --no-tags disables automatic tag following when 876 fetching from remote <name>. Setting it to --tags will fetch every 877 tag from remote <name>, even if they are not reachable from remote 878 branch heads. Passing these flags directly to linkgit:git-fetch[1] can 879 override this setting. See options --tags and --no-tags of 880 linkgit:git-fetch[1]. 881 882remote.<name>.vcs:: 883 Setting this to a value <vcs> will cause Git to interact with 884 the remote with the git-remote-<vcs> helper. 885 886remote.<name>.prune:: 887 When set to true, fetching from this remote by default will also 888 remove any remote-tracking references that no longer exist on the 889 remote (as if the `--prune` option was given on the command line). 890 Overrides `fetch.prune` settings, if any. 891 892remote.<name>.pruneTags:: 893 When set to true, fetching from this remote by default will also 894 remove any local tags that no longer exist on the remote if pruning 895 is activated in general via `remote.<name>.prune`, `fetch.prune` or 896 `--prune`. Overrides `fetch.pruneTags` settings, if any. 897+ 898See also `remote.<name>.prune` and the PRUNING section of 899linkgit:git-fetch[1]. 900 901remotes.<group>:: 902 The list of remotes which are fetched by "git remote update 903 <group>". See linkgit:git-remote[1]. 904 905repack.useDeltaBaseOffset:: 906 By default, linkgit:git-repack[1] creates packs that use 907 delta-base offset. If you need to share your repository with 908 Git older than version 1.4.4, either directly or via a dumb 909 protocol such as http, then you need to set this option to 910 "false" and repack. Access from old Git versions over the 911 native protocol are unaffected by this option. 912 913repack.packKeptObjects:: 914 If set to true, makes `git repack` act as if 915 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for 916 details. Defaults to `false` normally, but `true` if a bitmap 917 index is being written (either via `--write-bitmap-index` or 918 `repack.writeBitmaps`). 919 920repack.useDeltaIslands:: 921 If set to true, makes `git repack` act as if `--delta-islands` 922 was passed. Defaults to `false`. 923 924repack.writeBitmaps:: 925 When true, git will write a bitmap index when packing all 926 objects to disk (e.g., when `git repack -a` is run). This 927 index can speed up the "counting objects" phase of subsequent 928 packs created for clones and fetches, at the cost of some disk 929 space and extra time spent on the initial repack. This has 930 no effect if multiple packfiles are created. 931 Defaults to false. 932 933rerere.autoUpdate:: 934 When set to true, `git-rerere` updates the index with the 935 resulting contents after it cleanly resolves conflicts using 936 previously recorded resolution. Defaults to false. 937 938rerere.enabled:: 939 Activate recording of resolved conflicts, so that identical 940 conflict hunks can be resolved automatically, should they be 941 encountered again. By default, linkgit:git-rerere[1] is 942 enabled if there is an `rr-cache` directory under the 943 `$GIT_DIR`, e.g. if "rerere" was previously used in the 944 repository. 945 946reset.quiet:: 947 When set to true, 'git reset' will default to the '--quiet' option. 948 949include::sendemail-config.txt[] 950 951sequence.editor:: 952 Text editor used by `git rebase -i` for editing the rebase instruction file. 953 The value is meant to be interpreted by the shell when it is used. 954 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. 955 When not configured the default commit message editor is used instead. 956 957showBranch.default:: 958 The default set of branches for linkgit:git-show-branch[1]. 959 See linkgit:git-show-branch[1]. 960 961splitIndex.maxPercentChange:: 962 When the split index feature is used, this specifies the 963 percent of entries the split index can contain compared to the 964 total number of entries in both the split index and the shared 965 index before a new shared index is written. 966 The value should be between 0 and 100. If the value is 0 then 967 a new shared index is always written, if it is 100 a new 968 shared index is never written. 969 By default the value is 20, so a new shared index is written 970 if the number of entries in the split index would be greater 971 than 20 percent of the total number of entries. 972 See linkgit:git-update-index[1]. 973 974splitIndex.sharedIndexExpire:: 975 When the split index feature is used, shared index files that 976 were not modified since the time this variable specifies will 977 be removed when a new shared index file is created. The value 978 "now" expires all entries immediately, and "never" suppresses 979 expiration altogether. 980 The default value is "2.weeks.ago". 981 Note that a shared index file is considered modified (for the 982 purpose of expiration) each time a new split-index file is 983 either created based on it or read from it. 984 See linkgit:git-update-index[1]. 985 986include::config/ssh.txt[] 987 988status.relativePaths:: 989 By default, linkgit:git-status[1] shows paths relative to the 990 current directory. Setting this variable to `false` shows paths 991 relative to the repository root (this was the default for Git 992 prior to v1.5.4). 993 994status.short:: 995 Set to true to enable --short by default in linkgit:git-status[1]. 996 The option --no-short takes precedence over this variable. 997 998status.branch:: 999 Set to true to enable --branch by default in linkgit:git-status[1].1000 The option --no-branch takes precedence over this variable.10011002status.displayCommentPrefix::1003 If set to true, linkgit:git-status[1] will insert a comment1004 prefix before each output line (starting with1005 `core.commentChar`, i.e. `#` by default). This was the1006 behavior of linkgit:git-status[1] in Git 1.8.4 and previous.1007 Defaults to false.10081009status.renameLimit::1010 The number of files to consider when performing rename detection1011 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to1012 the value of diff.renameLimit.10131014status.renames::1015 Whether and how Git detects renames in linkgit:git-status[1] and1016 linkgit:git-commit[1] . If set to "false", rename detection is1017 disabled. If set to "true", basic rename detection is enabled.1018 If set to "copies" or "copy", Git will detect copies, as well.1019 Defaults to the value of diff.renames.10201021status.showStash::1022 If set to true, linkgit:git-status[1] will display the number of1023 entries currently stashed away.1024 Defaults to false.10251026status.showUntrackedFiles::1027 By default, linkgit:git-status[1] and linkgit:git-commit[1] show1028 files which are not currently tracked by Git. Directories which1029 contain only untracked files, are shown with the directory name1030 only. Showing untracked files means that Git needs to lstat() all1031 the files in the whole repository, which might be slow on some1032 systems. So, this variable controls how the commands displays1033 the untracked files. Possible values are:1034+1035--1036* `no` - Show no untracked files.1037* `normal` - Show untracked files and directories.1038* `all` - Show also individual files in untracked directories.1039--1040+1041If this variable is not specified, it defaults to 'normal'.1042This variable can be overridden with the -u|--untracked-files option1043of linkgit:git-status[1] and linkgit:git-commit[1].10441045status.submoduleSummary::1046 Defaults to false.1047 If this is set to a non zero number or true (identical to -1 or an1048 unlimited number), the submodule summary will be enabled and a1049 summary of commits for modified submodules will be shown (see1050 --summary-limit option of linkgit:git-submodule[1]). Please note1051 that the summary output command will be suppressed for all1052 submodules when `diff.ignoreSubmodules` is set to 'all' or only1053 for those submodules where `submodule.<name>.ignore=all`. The only1054 exception to that rule is that status and commit will show staged1055 submodule changes. To1056 also view the summary for ignored submodules you can either use1057 the --ignore-submodules=dirty command-line option or the 'git1058 submodule summary' command, which shows a similar output but does1059 not honor these settings.10601061stash.showPatch::1062 If this is set to true, the `git stash show` command without an1063 option will show the stash entry in patch form. Defaults to false.1064 See description of 'show' command in linkgit:git-stash[1].10651066stash.showStat::1067 If this is set to true, the `git stash show` command without an1068 option will show diffstat of the stash entry. Defaults to true.1069 See description of 'show' command in linkgit:git-stash[1].10701071include::submodule-config.txt[]10721073tag.forceSignAnnotated::1074 A boolean to specify whether annotated tags created should be GPG signed.1075 If `--annotate` is specified on the command line, it takes1076 precedence over this option.10771078tag.sort::1079 This variable controls the sort ordering of tags when displayed by1080 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the1081 value of this variable will be used as the default.10821083tar.umask::1084 This variable can be used to restrict the permission bits of1085 tar archive entries. The default is 0002, which turns off the1086 world write bit. The special value "user" indicates that the1087 archiving user's umask will be used instead. See umask(2) and1088 linkgit:git-archive[1].10891090transfer.fsckObjects::1091 When `fetch.fsckObjects` or `receive.fsckObjects` are1092 not set, the value of this variable is used instead.1093 Defaults to false.1094+1095When set, the fetch or receive will abort in the case of a malformed1096object or a link to a nonexistent object. In addition, various other1097issues are checked for, including legacy issues (see `fsck.<msg-id>`),1098and potential security issues like the existence of a `.GIT` directory1099or a malicious `.gitmodules` file (see the release notes for v2.2.11100and v2.17.1 for details). Other sanity and security checks may be1101added in future releases.1102+1103On the receiving side, failing fsckObjects will make those objects1104unreachable, see "QUARANTINE ENVIRONMENT" in1105linkgit:git-receive-pack[1]. On the fetch side, malformed objects will1106instead be left unreferenced in the repository.1107+1108Due to the non-quarantine nature of the `fetch.fsckObjects`1109implementation it can not be relied upon to leave the object store1110clean like `receive.fsckObjects` can.1111+1112As objects are unpacked they're written to the object store, so there1113can be cases where malicious objects get introduced even though the1114"fetch" failed, only to have a subsequent "fetch" succeed because only1115new incoming objects are checked, not those that have already been1116written to the object store. That difference in behavior should not be1117relied upon. In the future, such objects may be quarantined for1118"fetch" as well.1119+1120For now, the paranoid need to find some way to emulate the quarantine1121environment if they'd like the same protection as "push". E.g. in the1122case of an internal mirror do the mirroring in two steps, one to fetch1123the untrusted objects, and then do a second "push" (which will use the1124quarantine) to another internal repo, and have internal clients1125consume this pushed-to repository, or embargo internal fetches and1126only allow them once a full "fsck" has run (and no new fetches have1127happened in the meantime).11281129transfer.hideRefs::1130 String(s) `receive-pack` and `upload-pack` use to decide which1131 refs to omit from their initial advertisements. Use more than1132 one definition to specify multiple prefix strings. A ref that is1133 under the hierarchies listed in the value of this variable is1134 excluded, and is hidden when responding to `git push` or `git1135 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for1136 program-specific versions of this config.1137+1138You may also include a `!` in front of the ref name to negate the entry,1139explicitly exposing it, even if an earlier entry marked it as hidden.1140If you have multiple hideRefs values, later entries override earlier ones1141(and entries in more-specific config files override less-specific ones).1142+1143If a namespace is in use, the namespace prefix is stripped from each1144reference before it is matched against `transfer.hiderefs` patterns.1145For example, if `refs/heads/master` is specified in `transfer.hideRefs` and1146the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`1147is omitted from the advertisements but `refs/heads/master` and1148`refs/namespaces/bar/refs/heads/master` are still advertised as so-called1149"have" lines. In order to match refs before stripping, add a `^` in front of1150the ref name. If you combine `!` and `^`, `!` must be specified first.1151+1152Even if you hide refs, a client may still be able to steal the target1153objects via the techniques described in the "SECURITY" section of the1154linkgit:gitnamespaces[7] man page; it's best to keep private data in a1155separate repository.11561157transfer.unpackLimit::1158 When `fetch.unpackLimit` or `receive.unpackLimit` are1159 not set, the value of this variable is used instead.1160 The default value is 100.11611162uploadarchive.allowUnreachable::1163 If true, allow clients to use `git archive --remote` to request1164 any tree, whether reachable from the ref tips or not. See the1165 discussion in the "SECURITY" section of1166 linkgit:git-upload-archive[1] for more details. Defaults to1167 `false`.11681169uploadpack.hideRefs::1170 This variable is the same as `transfer.hideRefs`, but applies1171 only to `upload-pack` (and so affects only fetches, not pushes).1172 An attempt to fetch a hidden ref by `git fetch` will fail. See1173 also `uploadpack.allowTipSHA1InWant`.11741175uploadpack.allowTipSHA1InWant::1176 When `uploadpack.hideRefs` is in effect, allow `upload-pack`1177 to accept a fetch request that asks for an object at the tip1178 of a hidden ref (by default, such a request is rejected).1179 See also `uploadpack.hideRefs`. Even if this is false, a client1180 may be able to steal objects via the techniques described in the1181 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's1182 best to keep private data in a separate repository.11831184uploadpack.allowReachableSHA1InWant::1185 Allow `upload-pack` to accept a fetch request that asks for an1186 object that is reachable from any ref tip. However, note that1187 calculating object reachability is computationally expensive.1188 Defaults to `false`. Even if this is false, a client may be able1189 to steal objects via the techniques described in the "SECURITY"1190 section of the linkgit:gitnamespaces[7] man page; it's best to1191 keep private data in a separate repository.11921193uploadpack.allowAnySHA1InWant::1194 Allow `upload-pack` to accept a fetch request that asks for any1195 object at all.1196 Defaults to `false`.11971198uploadpack.keepAlive::1199 When `upload-pack` has started `pack-objects`, there may be a1200 quiet period while `pack-objects` prepares the pack. Normally1201 it would output progress information, but if `--quiet` was used1202 for the fetch, `pack-objects` will output nothing at all until1203 the pack data begins. Some clients and networks may consider1204 the server to be hung and give up. Setting this option instructs1205 `upload-pack` to send an empty keepalive packet every1206 `uploadpack.keepAlive` seconds. Setting this option to 01207 disables keepalive packets entirely. The default is 5 seconds.12081209uploadpack.packObjectsHook::1210 If this option is set, when `upload-pack` would run1211 `git pack-objects` to create a packfile for a client, it will1212 run this shell command instead. The `pack-objects` command and1213 arguments it _would_ have run (including the `git pack-objects`1214 at the beginning) are appended to the shell command. The stdin1215 and stdout of the hook are treated as if `pack-objects` itself1216 was run. I.e., `upload-pack` will feed input intended for1217 `pack-objects` to the hook, and expects a completed packfile on1218 stdout.1219+1220Note that this configuration variable is ignored if it is seen in the1221repository-level config (this is a safety measure against fetching from1222untrusted repositories).12231224uploadpack.allowFilter::1225 If this option is set, `upload-pack` will support partial1226 clone and partial fetch object filtering.12271228uploadpack.allowRefInWant::1229 If this option is set, `upload-pack` will support the `ref-in-want`1230 feature of the protocol version 2 `fetch` command. This feature1231 is intended for the benefit of load-balanced servers which may1232 not have the same view of what OIDs their refs point to due to1233 replication delay.12341235url.<base>.insteadOf::1236 Any URL that starts with this value will be rewritten to1237 start, instead, with <base>. In cases where some site serves a1238 large number of repositories, and serves them with multiple1239 access methods, and some users need to use different access1240 methods, this feature allows people to specify any of the1241 equivalent URLs and have Git automatically rewrite the URL to1242 the best alternative for the particular user, even for a1243 never-before-seen repository on the site. When more than one1244 insteadOf strings match a given URL, the longest match is used.1245+1246Note that any protocol restrictions will be applied to the rewritten1247URL. If the rewrite changes the URL to use a custom protocol or remote1248helper, you may need to adjust the `protocol.*.allow` config to permit1249the request. In particular, protocols you expect to use for submodules1250must be set to `always` rather than the default of `user`. See the1251description of `protocol.allow` above.12521253url.<base>.pushInsteadOf::1254 Any URL that starts with this value will not be pushed to;1255 instead, it will be rewritten to start with <base>, and the1256 resulting URL will be pushed to. In cases where some site serves1257 a large number of repositories, and serves them with multiple1258 access methods, some of which do not allow push, this feature1259 allows people to specify a pull-only URL and have Git1260 automatically use an appropriate URL to push, even for a1261 never-before-seen repository on the site. When more than one1262 pushInsteadOf strings match a given URL, the longest match is1263 used. If a remote has an explicit pushurl, Git will ignore this1264 setting for that remote.12651266user.email::1267 Your email address to be recorded in any newly created commits.1268 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and1269 `EMAIL` environment variables. See linkgit:git-commit-tree[1].12701271user.name::1272 Your full name to be recorded in any newly created commits.1273 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`1274 environment variables. See linkgit:git-commit-tree[1].12751276user.useConfigOnly::1277 Instruct Git to avoid trying to guess defaults for `user.email`1278 and `user.name`, and instead retrieve the values only from the1279 configuration. For example, if you have multiple email addresses1280 and would like to use a different one for each repository, then1281 with this configuration option set to `true` in the global config1282 along with a name, Git will prompt you to set up an email before1283 making new commits in a newly cloned repository.1284 Defaults to `false`.12851286user.signingKey::1287 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the1288 key you want it to automatically when creating a signed tag or1289 commit, you can override the default selection with this variable.1290 This option is passed unchanged to gpg's --local-user parameter,1291 so you may specify a key using any method that gpg supports.12921293versionsort.prereleaseSuffix (deprecated)::1294 Deprecated alias for `versionsort.suffix`. Ignored if1295 `versionsort.suffix` is set.12961297versionsort.suffix::1298 Even when version sort is used in linkgit:git-tag[1], tagnames1299 with the same base version but different suffixes are still sorted1300 lexicographically, resulting e.g. in prerelease tags appearing1301 after the main release (e.g. "1.0-rc1" after "1.0"). This1302 variable can be specified to determine the sorting order of tags1303 with different suffixes.1304+1305By specifying a single suffix in this variable, any tagname containing1306that suffix will appear before the corresponding main release. E.g. if1307the variable is set to "-rc", then all "1.0-rcX" tags will appear before1308"1.0". If specified multiple times, once per suffix, then the order of1309suffixes in the configuration will determine the sorting order of tagnames1310with those suffixes. E.g. if "-pre" appears before "-rc" in the1311configuration, then all "1.0-preX" tags will be listed before any1312"1.0-rcX" tags. The placement of the main release tag relative to tags1313with various suffixes can be determined by specifying the empty suffix1314among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and1315"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags1316are listed first, followed by "v4.8", then "v4.8-ckX" and finally1317"v4.8-bfsX".1318+1319If more than one suffixes match the same tagname, then that tagname will1320be sorted according to the suffix which starts at the earliest position in1321the tagname. If more than one different matching suffixes start at1322that earliest position, then that tagname will be sorted according to the1323longest of those suffixes.1324The sorting order between different suffixes is undefined if they are1325in multiple config files.13261327web.browser::1328 Specify a web browser that may be used by some commands.1329 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]1330 may use it.13311332worktree.guessRemote::1333 With `add`, if no branch argument, and neither of `-b` nor1334 `-B` nor `--detach` are given, the command defaults to1335 creating a new branch from HEAD. If `worktree.guessRemote` is1336 set to true, `worktree add` tries to find a remote-tracking1337 branch whose name uniquely matches the new branch name. If1338 such a branch exists, it is checked out and set as "upstream"1339 for the new branch. If no such match can be found, it falls1340 back to creating a new branch from the current HEAD.