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 366log.abbrevCommit:: 367 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 368 linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may 369 override this option with `--no-abbrev-commit`. 370 371log.date:: 372 Set the default date-time mode for the 'log' command. 373 Setting a value for log.date is similar to using 'git log''s 374 `--date` option. See linkgit:git-log[1] for details. 375 376log.decorate:: 377 Print out the ref names of any commits that are shown by the log 378 command. If 'short' is specified, the ref name prefixes 'refs/heads/', 379 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is 380 specified, the full ref name (including prefix) will be printed. 381 If 'auto' is specified, then if the output is going to a terminal, 382 the ref names are shown as if 'short' were given, otherwise no ref 383 names are shown. This is the same as the `--decorate` option 384 of the `git log`. 385 386log.follow:: 387 If `true`, `git log` will act as if the `--follow` option was used when 388 a single <path> is given. This has the same limitations as `--follow`, 389 i.e. it cannot be used to follow multiple files and does not work well 390 on non-linear history. 391 392log.graphColors:: 393 A list of colors, separated by commas, that can be used to draw 394 history lines in `git log --graph`. 395 396log.showRoot:: 397 If true, the initial commit will be shown as a big creation event. 398 This is equivalent to a diff against an empty tree. 399 Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which 400 normally hide the root commit will now show it. True by default. 401 402log.showSignature:: 403 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 404 linkgit:git-whatchanged[1] assume `--show-signature`. 405 406log.mailmap:: 407 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 408 linkgit:git-whatchanged[1] assume `--use-mailmap`. 409 410mailinfo.scissors:: 411 If true, makes linkgit:git-mailinfo[1] (and therefore 412 linkgit:git-am[1]) act by default as if the --scissors option 413 was provided on the command-line. When active, this features 414 removes everything from the message body before a scissors 415 line (i.e. consisting mainly of ">8", "8<" and "-"). 416 417mailmap.file:: 418 The location of an augmenting mailmap file. The default 419 mailmap, located in the root of the repository, is loaded 420 first, then the mailmap file pointed to by this variable. 421 The location of the mailmap file may be in a repository 422 subdirectory, or somewhere outside of the repository itself. 423 See linkgit:git-shortlog[1] and linkgit:git-blame[1]. 424 425mailmap.blob:: 426 Like `mailmap.file`, but consider the value as a reference to a 427 blob in the repository. If both `mailmap.file` and 428 `mailmap.blob` are given, both are parsed, with entries from 429 `mailmap.file` taking precedence. In a bare repository, this 430 defaults to `HEAD:.mailmap`. In a non-bare repository, it 431 defaults to empty. 432 433man.viewer:: 434 Specify the programs that may be used to display help in the 435 'man' format. See linkgit:git-help[1]. 436 437man.<tool>.cmd:: 438 Specify the command to invoke the specified man viewer. The 439 specified command is evaluated in shell with the man page 440 passed as argument. (See linkgit:git-help[1].) 441 442man.<tool>.path:: 443 Override the path for the given tool that may be used to 444 display help in the 'man' format. See linkgit:git-help[1]. 445 446include::merge-config.txt[] 447 448mergetool.<tool>.path:: 449 Override the path for the given tool. This is useful in case 450 your tool is not in the PATH. 451 452mergetool.<tool>.cmd:: 453 Specify the command to invoke the specified merge tool. The 454 specified command is evaluated in shell with the following 455 variables available: 'BASE' is the name of a temporary file 456 containing the common base of the files to be merged, if available; 457 'LOCAL' is the name of a temporary file containing the contents of 458 the file on the current branch; 'REMOTE' is the name of a temporary 459 file containing the contents of the file from the branch being 460 merged; 'MERGED' contains the name of the file to which the merge 461 tool should write the results of a successful merge. 462 463mergetool.<tool>.trustExitCode:: 464 For a custom merge command, specify whether the exit code of 465 the merge command can be used to determine whether the merge was 466 successful. If this is not set to true then the merge target file 467 timestamp is checked and the merge assumed to have been successful 468 if the file has been updated, otherwise the user is prompted to 469 indicate the success of the merge. 470 471mergetool.meld.hasOutput:: 472 Older versions of `meld` do not support the `--output` option. 473 Git will attempt to detect whether `meld` supports `--output` 474 by inspecting the output of `meld --help`. Configuring 475 `mergetool.meld.hasOutput` will make Git skip these checks and 476 use the configured value instead. Setting `mergetool.meld.hasOutput` 477 to `true` tells Git to unconditionally use the `--output` option, 478 and `false` avoids using `--output`. 479 480mergetool.keepBackup:: 481 After performing a merge, the original file with conflict markers 482 can be saved as a file with a `.orig` extension. If this variable 483 is set to `false` then this file is not preserved. Defaults to 484 `true` (i.e. keep the backup files). 485 486mergetool.keepTemporaries:: 487 When invoking a custom merge tool, Git uses a set of temporary 488 files to pass to the tool. If the tool returns an error and this 489 variable is set to `true`, then these temporary files will be 490 preserved, otherwise they will be removed after the tool has 491 exited. Defaults to `false`. 492 493mergetool.writeToTemp:: 494 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of 495 conflicting files in the worktree by default. Git will attempt 496 to use a temporary directory for these files when set `true`. 497 Defaults to `false`. 498 499mergetool.prompt:: 500 Prompt before each invocation of the merge resolution program. 501 502notes.mergeStrategy:: 503 Which merge strategy to choose by default when resolving notes 504 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or 505 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" 506 section of linkgit:git-notes[1] for more information on each strategy. 507 508notes.<name>.mergeStrategy:: 509 Which merge strategy to choose when doing a notes merge into 510 refs/notes/<name>. This overrides the more general 511 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in 512 linkgit:git-notes[1] for more information on the available strategies. 513 514notes.displayRef:: 515 The (fully qualified) refname from which to show notes when 516 showing commit messages. The value of this variable can be set 517 to a glob, in which case notes from all matching refs will be 518 shown. You may also specify this configuration variable 519 several times. A warning will be issued for refs that do not 520 exist, but a glob that does not match any refs is silently 521 ignored. 522+ 523This setting can be overridden with the `GIT_NOTES_DISPLAY_REF` 524environment variable, which must be a colon separated list of refs or 525globs. 526+ 527The effective value of "core.notesRef" (possibly overridden by 528GIT_NOTES_REF) is also implicitly added to the list of refs to be 529displayed. 530 531notes.rewrite.<command>:: 532 When rewriting commits with <command> (currently `amend` or 533 `rebase`) and this variable is set to `true`, Git 534 automatically copies your notes from the original to the 535 rewritten commit. Defaults to `true`, but see 536 "notes.rewriteRef" below. 537 538notes.rewriteMode:: 539 When copying notes during a rewrite (see the 540 "notes.rewrite.<command>" option), determines what to do if 541 the target commit already has a note. Must be one of 542 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. 543 Defaults to `concatenate`. 544+ 545This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` 546environment variable. 547 548notes.rewriteRef:: 549 When copying notes during a rewrite, specifies the (fully 550 qualified) ref whose notes should be copied. The ref may be a 551 glob, in which case notes in all matching refs will be copied. 552 You may also specify this configuration several times. 553+ 554Does not have a default value; you must configure this variable to 555enable note rewriting. Set it to `refs/notes/commits` to enable 556rewriting for the default commit notes. 557+ 558This setting can be overridden with the `GIT_NOTES_REWRITE_REF` 559environment variable, which must be a colon separated list of refs or 560globs. 561 562pack.window:: 563 The size of the window used by linkgit:git-pack-objects[1] when no 564 window size is given on the command line. Defaults to 10. 565 566pack.depth:: 567 The maximum delta depth used by linkgit:git-pack-objects[1] when no 568 maximum depth is given on the command line. Defaults to 50. 569 Maximum value is 4095. 570 571pack.windowMemory:: 572 The maximum size of memory that is consumed by each thread 573 in linkgit:git-pack-objects[1] for pack window memory when 574 no limit is given on the command line. The value can be 575 suffixed with "k", "m", or "g". When left unconfigured (or 576 set explicitly to 0), there will be no limit. 577 578pack.compression:: 579 An integer -1..9, indicating the compression level for objects 580 in a pack file. -1 is the zlib default. 0 means no 581 compression, and 1..9 are various speed/size tradeoffs, 9 being 582 slowest. If not set, defaults to core.compression. If that is 583 not set, defaults to -1, the zlib default, which is "a default 584 compromise between speed and compression (currently equivalent 585 to level 6)." 586+ 587Note that changing the compression level will not automatically recompress 588all existing objects. You can force recompression by passing the -F option 589to linkgit:git-repack[1]. 590 591pack.island:: 592 An extended regular expression configuring a set of delta 593 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] 594 for details. 595 596pack.islandCore:: 597 Specify an island name which gets to have its objects be 598 packed first. This creates a kind of pseudo-pack at the front 599 of one pack, so that the objects from the specified island are 600 hopefully faster to copy into any pack that should be served 601 to a user requesting these objects. In practice this means 602 that the island specified should likely correspond to what is 603 the most commonly cloned in the repo. See also "DELTA ISLANDS" 604 in linkgit:git-pack-objects[1]. 605 606pack.deltaCacheSize:: 607 The maximum memory in bytes used for caching deltas in 608 linkgit:git-pack-objects[1] before writing them out to a pack. 609 This cache is used to speed up the writing object phase by not 610 having to recompute the final delta result once the best match 611 for all objects is found. Repacking large repositories on machines 612 which are tight with memory might be badly impacted by this though, 613 especially if this cache pushes the system into swapping. 614 A value of 0 means no limit. The smallest size of 1 byte may be 615 used to virtually disable this cache. Defaults to 256 MiB. 616 617pack.deltaCacheLimit:: 618 The maximum size of a delta, that is cached in 619 linkgit:git-pack-objects[1]. This cache is used to speed up the 620 writing object phase by not having to recompute the final delta 621 result once the best match for all objects is found. 622 Defaults to 1000. Maximum value is 65535. 623 624pack.threads:: 625 Specifies the number of threads to spawn when searching for best 626 delta matches. This requires that linkgit:git-pack-objects[1] 627 be compiled with pthreads otherwise this option is ignored with a 628 warning. This is meant to reduce packing time on multiprocessor 629 machines. The required amount of memory for the delta search window 630 is however multiplied by the number of threads. 631 Specifying 0 will cause Git to auto-detect the number of CPU's 632 and set the number of threads accordingly. 633 634pack.indexVersion:: 635 Specify the default pack index version. Valid values are 1 for 636 legacy pack index used by Git versions prior to 1.5.2, and 2 for 637 the new pack index with capabilities for packs larger than 4 GB 638 as well as proper protection against the repacking of corrupted 639 packs. Version 2 is the default. Note that version 2 is enforced 640 and this config option ignored whenever the corresponding pack is 641 larger than 2 GB. 642+ 643If you have an old Git that does not understand the version 2 `*.idx` file, 644cloning or fetching over a non native protocol (e.g. "http") 645that will copy both `*.pack` file and corresponding `*.idx` file from the 646other side may give you a repository that cannot be accessed with your 647older version of Git. If the `*.pack` file is smaller than 2 GB, however, 648you can use linkgit:git-index-pack[1] on the *.pack file to regenerate 649the `*.idx` file. 650 651pack.packSizeLimit:: 652 The maximum size of a pack. This setting only affects 653 packing to a file when repacking, i.e. the git:// protocol 654 is unaffected. It can be overridden by the `--max-pack-size` 655 option of linkgit:git-repack[1]. Reaching this limit results 656 in the creation of multiple packfiles; which in turn prevents 657 bitmaps from being created. 658 The minimum size allowed is limited to 1 MiB. 659 The default is unlimited. 660 Common unit suffixes of 'k', 'm', or 'g' are 661 supported. 662 663pack.useBitmaps:: 664 When true, git will use pack bitmaps (if available) when packing 665 to stdout (e.g., during the server side of a fetch). Defaults to 666 true. You should not generally need to turn this off unless 667 you are debugging pack bitmaps. 668 669pack.writeBitmaps (deprecated):: 670 This is a deprecated synonym for `repack.writeBitmaps`. 671 672pack.writeBitmapHashCache:: 673 When true, git will include a "hash cache" section in the bitmap 674 index (if one is written). This cache can be used to feed git's 675 delta heuristics, potentially leading to better deltas between 676 bitmapped and non-bitmapped objects (e.g., when serving a fetch 677 between an older, bitmapped pack and objects that have been 678 pushed since the last gc). The downside is that it consumes 4 679 bytes per object of disk space, and that JGit's bitmap 680 implementation does not understand it, causing it to complain if 681 Git and JGit are used on the same repository. Defaults to false. 682 683pager.<cmd>:: 684 If the value is boolean, turns on or off pagination of the 685 output of a particular Git subcommand when writing to a tty. 686 Otherwise, turns on pagination for the subcommand using the 687 pager specified by the value of `pager.<cmd>`. If `--paginate` 688 or `--no-pager` is specified on the command line, it takes 689 precedence over this option. To disable pagination for all 690 commands, set `core.pager` or `GIT_PAGER` to `cat`. 691 692pretty.<name>:: 693 Alias for a --pretty= format string, as specified in 694 linkgit:git-log[1]. Any aliases defined here can be used just 695 as the built-in pretty formats could. For example, 696 running `git config pretty.changelog "format:* %H %s"` 697 would cause the invocation `git log --pretty=changelog` 698 to be equivalent to running `git log "--pretty=format:* %H %s"`. 699 Note that an alias with the same name as a built-in format 700 will be silently ignored. 701 702protocol.allow:: 703 If set, provide a user defined default policy for all protocols which 704 don't explicitly have a policy (`protocol.<name>.allow`). By default, 705 if unset, known-safe protocols (http, https, git, ssh, file) have a 706 default policy of `always`, known-dangerous protocols (ext) have a 707 default policy of `never`, and all other protocols have a default 708 policy of `user`. Supported policies: 709+ 710-- 711 712* `always` - protocol is always able to be used. 713 714* `never` - protocol is never able to be used. 715 716* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is 717 either unset or has a value of 1. This policy should be used when you want a 718 protocol to be directly usable by the user but don't want it used by commands which 719 execute clone/fetch/push commands without user input, e.g. recursive 720 submodule initialization. 721 722-- 723 724protocol.<name>.allow:: 725 Set a policy to be used by protocol `<name>` with clone/fetch/push 726 commands. See `protocol.allow` above for the available policies. 727+ 728The protocol names currently used by git are: 729+ 730-- 731 - `file`: any local file-based path (including `file://` URLs, 732 or local paths) 733 734 - `git`: the anonymous git protocol over a direct TCP 735 connection (or proxy, if configured) 736 737 - `ssh`: git over ssh (including `host:path` syntax, 738 `ssh://`, etc). 739 740 - `http`: git over http, both "smart http" and "dumb http". 741 Note that this does _not_ include `https`; if you want to configure 742 both, you must do so individually. 743 744 - any external helpers are named by their protocol (e.g., use 745 `hg` to allow the `git-remote-hg` helper) 746-- 747 748protocol.version:: 749 Experimental. If set, clients will attempt to communicate with a 750 server using the specified protocol version. If unset, no 751 attempt will be made by the client to communicate using a 752 particular protocol version, this results in protocol version 0 753 being used. 754 Supported versions: 755+ 756-- 757 758* `0` - the original wire protocol. 759 760* `1` - the original wire protocol with the addition of a version string 761 in the initial response from the server. 762 763* `2` - link:technical/protocol-v2.html[wire protocol version 2]. 764 765-- 766 767include::pull-config.txt[] 768 769include::push-config.txt[] 770 771include::rebase-config.txt[] 772 773include::receive-config.txt[] 774 775remote.pushDefault:: 776 The remote to push to by default. Overrides 777 `branch.<name>.remote` for all branches, and is overridden by 778 `branch.<name>.pushRemote` for specific branches. 779 780remote.<name>.url:: 781 The URL of a remote repository. See linkgit:git-fetch[1] or 782 linkgit:git-push[1]. 783 784remote.<name>.pushurl:: 785 The push URL of a remote repository. See linkgit:git-push[1]. 786 787remote.<name>.proxy:: 788 For remotes that require curl (http, https and ftp), the URL to 789 the proxy to use for that remote. Set to the empty string to 790 disable proxying for that remote. 791 792remote.<name>.proxyAuthMethod:: 793 For remotes that require curl (http, https and ftp), the method to use for 794 authenticating against the proxy in use (probably set in 795 `remote.<name>.proxy`). See `http.proxyAuthMethod`. 796 797remote.<name>.fetch:: 798 The default set of "refspec" for linkgit:git-fetch[1]. See 799 linkgit:git-fetch[1]. 800 801remote.<name>.push:: 802 The default set of "refspec" for linkgit:git-push[1]. See 803 linkgit:git-push[1]. 804 805remote.<name>.mirror:: 806 If true, pushing to this remote will automatically behave 807 as if the `--mirror` option was given on the command line. 808 809remote.<name>.skipDefaultUpdate:: 810 If true, this remote will be skipped by default when updating 811 using linkgit:git-fetch[1] or the `update` subcommand of 812 linkgit:git-remote[1]. 813 814remote.<name>.skipFetchAll:: 815 If true, this remote will be skipped by default when updating 816 using linkgit:git-fetch[1] or the `update` subcommand of 817 linkgit:git-remote[1]. 818 819remote.<name>.receivepack:: 820 The default program to execute on the remote side when pushing. See 821 option --receive-pack of linkgit:git-push[1]. 822 823remote.<name>.uploadpack:: 824 The default program to execute on the remote side when fetching. See 825 option --upload-pack of linkgit:git-fetch-pack[1]. 826 827remote.<name>.tagOpt:: 828 Setting this value to --no-tags disables automatic tag following when 829 fetching from remote <name>. Setting it to --tags will fetch every 830 tag from remote <name>, even if they are not reachable from remote 831 branch heads. Passing these flags directly to linkgit:git-fetch[1] can 832 override this setting. See options --tags and --no-tags of 833 linkgit:git-fetch[1]. 834 835remote.<name>.vcs:: 836 Setting this to a value <vcs> will cause Git to interact with 837 the remote with the git-remote-<vcs> helper. 838 839remote.<name>.prune:: 840 When set to true, fetching from this remote by default will also 841 remove any remote-tracking references that no longer exist on the 842 remote (as if the `--prune` option was given on the command line). 843 Overrides `fetch.prune` settings, if any. 844 845remote.<name>.pruneTags:: 846 When set to true, fetching from this remote by default will also 847 remove any local tags that no longer exist on the remote if pruning 848 is activated in general via `remote.<name>.prune`, `fetch.prune` or 849 `--prune`. Overrides `fetch.pruneTags` settings, if any. 850+ 851See also `remote.<name>.prune` and the PRUNING section of 852linkgit:git-fetch[1]. 853 854remotes.<group>:: 855 The list of remotes which are fetched by "git remote update 856 <group>". See linkgit:git-remote[1]. 857 858repack.useDeltaBaseOffset:: 859 By default, linkgit:git-repack[1] creates packs that use 860 delta-base offset. If you need to share your repository with 861 Git older than version 1.4.4, either directly or via a dumb 862 protocol such as http, then you need to set this option to 863 "false" and repack. Access from old Git versions over the 864 native protocol are unaffected by this option. 865 866repack.packKeptObjects:: 867 If set to true, makes `git repack` act as if 868 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for 869 details. Defaults to `false` normally, but `true` if a bitmap 870 index is being written (either via `--write-bitmap-index` or 871 `repack.writeBitmaps`). 872 873repack.useDeltaIslands:: 874 If set to true, makes `git repack` act as if `--delta-islands` 875 was passed. Defaults to `false`. 876 877repack.writeBitmaps:: 878 When true, git will write a bitmap index when packing all 879 objects to disk (e.g., when `git repack -a` is run). This 880 index can speed up the "counting objects" phase of subsequent 881 packs created for clones and fetches, at the cost of some disk 882 space and extra time spent on the initial repack. This has 883 no effect if multiple packfiles are created. 884 Defaults to false. 885 886rerere.autoUpdate:: 887 When set to true, `git-rerere` updates the index with the 888 resulting contents after it cleanly resolves conflicts using 889 previously recorded resolution. Defaults to false. 890 891rerere.enabled:: 892 Activate recording of resolved conflicts, so that identical 893 conflict hunks can be resolved automatically, should they be 894 encountered again. By default, linkgit:git-rerere[1] is 895 enabled if there is an `rr-cache` directory under the 896 `$GIT_DIR`, e.g. if "rerere" was previously used in the 897 repository. 898 899reset.quiet:: 900 When set to true, 'git reset' will default to the '--quiet' option. 901 902include::sendemail-config.txt[] 903 904sequence.editor:: 905 Text editor used by `git rebase -i` for editing the rebase instruction file. 906 The value is meant to be interpreted by the shell when it is used. 907 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. 908 When not configured the default commit message editor is used instead. 909 910showBranch.default:: 911 The default set of branches for linkgit:git-show-branch[1]. 912 See linkgit:git-show-branch[1]. 913 914splitIndex.maxPercentChange:: 915 When the split index feature is used, this specifies the 916 percent of entries the split index can contain compared to the 917 total number of entries in both the split index and the shared 918 index before a new shared index is written. 919 The value should be between 0 and 100. If the value is 0 then 920 a new shared index is always written, if it is 100 a new 921 shared index is never written. 922 By default the value is 20, so a new shared index is written 923 if the number of entries in the split index would be greater 924 than 20 percent of the total number of entries. 925 See linkgit:git-update-index[1]. 926 927splitIndex.sharedIndexExpire:: 928 When the split index feature is used, shared index files that 929 were not modified since the time this variable specifies will 930 be removed when a new shared index file is created. The value 931 "now" expires all entries immediately, and "never" suppresses 932 expiration altogether. 933 The default value is "2.weeks.ago". 934 Note that a shared index file is considered modified (for the 935 purpose of expiration) each time a new split-index file is 936 either created based on it or read from it. 937 See linkgit:git-update-index[1]. 938 939include::config/ssh.txt[] 940 941status.relativePaths:: 942 By default, linkgit:git-status[1] shows paths relative to the 943 current directory. Setting this variable to `false` shows paths 944 relative to the repository root (this was the default for Git 945 prior to v1.5.4). 946 947status.short:: 948 Set to true to enable --short by default in linkgit:git-status[1]. 949 The option --no-short takes precedence over this variable. 950 951status.branch:: 952 Set to true to enable --branch by default in linkgit:git-status[1]. 953 The option --no-branch takes precedence over this variable. 954 955status.displayCommentPrefix:: 956 If set to true, linkgit:git-status[1] will insert a comment 957 prefix before each output line (starting with 958 `core.commentChar`, i.e. `#` by default). This was the 959 behavior of linkgit:git-status[1] in Git 1.8.4 and previous. 960 Defaults to false. 961 962status.renameLimit:: 963 The number of files to consider when performing rename detection 964 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to 965 the value of diff.renameLimit. 966 967status.renames:: 968 Whether and how Git detects renames in linkgit:git-status[1] and 969 linkgit:git-commit[1] . If set to "false", rename detection is 970 disabled. If set to "true", basic rename detection is enabled. 971 If set to "copies" or "copy", Git will detect copies, as well. 972 Defaults to the value of diff.renames. 973 974status.showStash:: 975 If set to true, linkgit:git-status[1] will display the number of 976 entries currently stashed away. 977 Defaults to false. 978 979status.showUntrackedFiles:: 980 By default, linkgit:git-status[1] and linkgit:git-commit[1] show 981 files which are not currently tracked by Git. Directories which 982 contain only untracked files, are shown with the directory name 983 only. Showing untracked files means that Git needs to lstat() all 984 the files in the whole repository, which might be slow on some 985 systems. So, this variable controls how the commands displays 986 the untracked files. Possible values are: 987+ 988-- 989* `no` - Show no untracked files. 990* `normal` - Show untracked files and directories. 991* `all` - Show also individual files in untracked directories. 992-- 993+ 994If this variable is not specified, it defaults to 'normal'. 995This variable can be overridden with the -u|--untracked-files option 996of linkgit:git-status[1] and linkgit:git-commit[1]. 997 998status.submoduleSummary:: 999 Defaults to false.1000 If this is set to a non zero number or true (identical to -1 or an1001 unlimited number), the submodule summary will be enabled and a1002 summary of commits for modified submodules will be shown (see1003 --summary-limit option of linkgit:git-submodule[1]). Please note1004 that the summary output command will be suppressed for all1005 submodules when `diff.ignoreSubmodules` is set to 'all' or only1006 for those submodules where `submodule.<name>.ignore=all`. The only1007 exception to that rule is that status and commit will show staged1008 submodule changes. To1009 also view the summary for ignored submodules you can either use1010 the --ignore-submodules=dirty command-line option or the 'git1011 submodule summary' command, which shows a similar output but does1012 not honor these settings.10131014stash.showPatch::1015 If this is set to true, the `git stash show` command without an1016 option will show the stash entry in patch form. Defaults to false.1017 See description of 'show' command in linkgit:git-stash[1].10181019stash.showStat::1020 If this is set to true, the `git stash show` command without an1021 option will show diffstat of the stash entry. Defaults to true.1022 See description of 'show' command in linkgit:git-stash[1].10231024include::submodule-config.txt[]10251026tag.forceSignAnnotated::1027 A boolean to specify whether annotated tags created should be GPG signed.1028 If `--annotate` is specified on the command line, it takes1029 precedence over this option.10301031tag.sort::1032 This variable controls the sort ordering of tags when displayed by1033 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the1034 value of this variable will be used as the default.10351036tar.umask::1037 This variable can be used to restrict the permission bits of1038 tar archive entries. The default is 0002, which turns off the1039 world write bit. The special value "user" indicates that the1040 archiving user's umask will be used instead. See umask(2) and1041 linkgit:git-archive[1].10421043transfer.fsckObjects::1044 When `fetch.fsckObjects` or `receive.fsckObjects` are1045 not set, the value of this variable is used instead.1046 Defaults to false.1047+1048When set, the fetch or receive will abort in the case of a malformed1049object or a link to a nonexistent object. In addition, various other1050issues are checked for, including legacy issues (see `fsck.<msg-id>`),1051and potential security issues like the existence of a `.GIT` directory1052or a malicious `.gitmodules` file (see the release notes for v2.2.11053and v2.17.1 for details). Other sanity and security checks may be1054added in future releases.1055+1056On the receiving side, failing fsckObjects will make those objects1057unreachable, see "QUARANTINE ENVIRONMENT" in1058linkgit:git-receive-pack[1]. On the fetch side, malformed objects will1059instead be left unreferenced in the repository.1060+1061Due to the non-quarantine nature of the `fetch.fsckObjects`1062implementation it can not be relied upon to leave the object store1063clean like `receive.fsckObjects` can.1064+1065As objects are unpacked they're written to the object store, so there1066can be cases where malicious objects get introduced even though the1067"fetch" failed, only to have a subsequent "fetch" succeed because only1068new incoming objects are checked, not those that have already been1069written to the object store. That difference in behavior should not be1070relied upon. In the future, such objects may be quarantined for1071"fetch" as well.1072+1073For now, the paranoid need to find some way to emulate the quarantine1074environment if they'd like the same protection as "push". E.g. in the1075case of an internal mirror do the mirroring in two steps, one to fetch1076the untrusted objects, and then do a second "push" (which will use the1077quarantine) to another internal repo, and have internal clients1078consume this pushed-to repository, or embargo internal fetches and1079only allow them once a full "fsck" has run (and no new fetches have1080happened in the meantime).10811082transfer.hideRefs::1083 String(s) `receive-pack` and `upload-pack` use to decide which1084 refs to omit from their initial advertisements. Use more than1085 one definition to specify multiple prefix strings. A ref that is1086 under the hierarchies listed in the value of this variable is1087 excluded, and is hidden when responding to `git push` or `git1088 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for1089 program-specific versions of this config.1090+1091You may also include a `!` in front of the ref name to negate the entry,1092explicitly exposing it, even if an earlier entry marked it as hidden.1093If you have multiple hideRefs values, later entries override earlier ones1094(and entries in more-specific config files override less-specific ones).1095+1096If a namespace is in use, the namespace prefix is stripped from each1097reference before it is matched against `transfer.hiderefs` patterns.1098For example, if `refs/heads/master` is specified in `transfer.hideRefs` and1099the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`1100is omitted from the advertisements but `refs/heads/master` and1101`refs/namespaces/bar/refs/heads/master` are still advertised as so-called1102"have" lines. In order to match refs before stripping, add a `^` in front of1103the ref name. If you combine `!` and `^`, `!` must be specified first.1104+1105Even if you hide refs, a client may still be able to steal the target1106objects via the techniques described in the "SECURITY" section of the1107linkgit:gitnamespaces[7] man page; it's best to keep private data in a1108separate repository.11091110transfer.unpackLimit::1111 When `fetch.unpackLimit` or `receive.unpackLimit` are1112 not set, the value of this variable is used instead.1113 The default value is 100.11141115uploadarchive.allowUnreachable::1116 If true, allow clients to use `git archive --remote` to request1117 any tree, whether reachable from the ref tips or not. See the1118 discussion in the "SECURITY" section of1119 linkgit:git-upload-archive[1] for more details. Defaults to1120 `false`.11211122uploadpack.hideRefs::1123 This variable is the same as `transfer.hideRefs`, but applies1124 only to `upload-pack` (and so affects only fetches, not pushes).1125 An attempt to fetch a hidden ref by `git fetch` will fail. See1126 also `uploadpack.allowTipSHA1InWant`.11271128uploadpack.allowTipSHA1InWant::1129 When `uploadpack.hideRefs` is in effect, allow `upload-pack`1130 to accept a fetch request that asks for an object at the tip1131 of a hidden ref (by default, such a request is rejected).1132 See also `uploadpack.hideRefs`. Even if this is false, a client1133 may be able to steal objects via the techniques described in the1134 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's1135 best to keep private data in a separate repository.11361137uploadpack.allowReachableSHA1InWant::1138 Allow `upload-pack` to accept a fetch request that asks for an1139 object that is reachable from any ref tip. However, note that1140 calculating object reachability is computationally expensive.1141 Defaults to `false`. Even if this is false, a client may be able1142 to steal objects via the techniques described in the "SECURITY"1143 section of the linkgit:gitnamespaces[7] man page; it's best to1144 keep private data in a separate repository.11451146uploadpack.allowAnySHA1InWant::1147 Allow `upload-pack` to accept a fetch request that asks for any1148 object at all.1149 Defaults to `false`.11501151uploadpack.keepAlive::1152 When `upload-pack` has started `pack-objects`, there may be a1153 quiet period while `pack-objects` prepares the pack. Normally1154 it would output progress information, but if `--quiet` was used1155 for the fetch, `pack-objects` will output nothing at all until1156 the pack data begins. Some clients and networks may consider1157 the server to be hung and give up. Setting this option instructs1158 `upload-pack` to send an empty keepalive packet every1159 `uploadpack.keepAlive` seconds. Setting this option to 01160 disables keepalive packets entirely. The default is 5 seconds.11611162uploadpack.packObjectsHook::1163 If this option is set, when `upload-pack` would run1164 `git pack-objects` to create a packfile for a client, it will1165 run this shell command instead. The `pack-objects` command and1166 arguments it _would_ have run (including the `git pack-objects`1167 at the beginning) are appended to the shell command. The stdin1168 and stdout of the hook are treated as if `pack-objects` itself1169 was run. I.e., `upload-pack` will feed input intended for1170 `pack-objects` to the hook, and expects a completed packfile on1171 stdout.1172+1173Note that this configuration variable is ignored if it is seen in the1174repository-level config (this is a safety measure against fetching from1175untrusted repositories).11761177uploadpack.allowFilter::1178 If this option is set, `upload-pack` will support partial1179 clone and partial fetch object filtering.11801181uploadpack.allowRefInWant::1182 If this option is set, `upload-pack` will support the `ref-in-want`1183 feature of the protocol version 2 `fetch` command. This feature1184 is intended for the benefit of load-balanced servers which may1185 not have the same view of what OIDs their refs point to due to1186 replication delay.11871188url.<base>.insteadOf::1189 Any URL that starts with this value will be rewritten to1190 start, instead, with <base>. In cases where some site serves a1191 large number of repositories, and serves them with multiple1192 access methods, and some users need to use different access1193 methods, this feature allows people to specify any of the1194 equivalent URLs and have Git automatically rewrite the URL to1195 the best alternative for the particular user, even for a1196 never-before-seen repository on the site. When more than one1197 insteadOf strings match a given URL, the longest match is used.1198+1199Note that any protocol restrictions will be applied to the rewritten1200URL. If the rewrite changes the URL to use a custom protocol or remote1201helper, you may need to adjust the `protocol.*.allow` config to permit1202the request. In particular, protocols you expect to use for submodules1203must be set to `always` rather than the default of `user`. See the1204description of `protocol.allow` above.12051206url.<base>.pushInsteadOf::1207 Any URL that starts with this value will not be pushed to;1208 instead, it will be rewritten to start with <base>, and the1209 resulting URL will be pushed to. In cases where some site serves1210 a large number of repositories, and serves them with multiple1211 access methods, some of which do not allow push, this feature1212 allows people to specify a pull-only URL and have Git1213 automatically use an appropriate URL to push, even for a1214 never-before-seen repository on the site. When more than one1215 pushInsteadOf strings match a given URL, the longest match is1216 used. If a remote has an explicit pushurl, Git will ignore this1217 setting for that remote.12181219user.email::1220 Your email address to be recorded in any newly created commits.1221 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and1222 `EMAIL` environment variables. See linkgit:git-commit-tree[1].12231224user.name::1225 Your full name to be recorded in any newly created commits.1226 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`1227 environment variables. See linkgit:git-commit-tree[1].12281229user.useConfigOnly::1230 Instruct Git to avoid trying to guess defaults for `user.email`1231 and `user.name`, and instead retrieve the values only from the1232 configuration. For example, if you have multiple email addresses1233 and would like to use a different one for each repository, then1234 with this configuration option set to `true` in the global config1235 along with a name, Git will prompt you to set up an email before1236 making new commits in a newly cloned repository.1237 Defaults to `false`.12381239user.signingKey::1240 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the1241 key you want it to automatically when creating a signed tag or1242 commit, you can override the default selection with this variable.1243 This option is passed unchanged to gpg's --local-user parameter,1244 so you may specify a key using any method that gpg supports.12451246versionsort.prereleaseSuffix (deprecated)::1247 Deprecated alias for `versionsort.suffix`. Ignored if1248 `versionsort.suffix` is set.12491250versionsort.suffix::1251 Even when version sort is used in linkgit:git-tag[1], tagnames1252 with the same base version but different suffixes are still sorted1253 lexicographically, resulting e.g. in prerelease tags appearing1254 after the main release (e.g. "1.0-rc1" after "1.0"). This1255 variable can be specified to determine the sorting order of tags1256 with different suffixes.1257+1258By specifying a single suffix in this variable, any tagname containing1259that suffix will appear before the corresponding main release. E.g. if1260the variable is set to "-rc", then all "1.0-rcX" tags will appear before1261"1.0". If specified multiple times, once per suffix, then the order of1262suffixes in the configuration will determine the sorting order of tagnames1263with those suffixes. E.g. if "-pre" appears before "-rc" in the1264configuration, then all "1.0-preX" tags will be listed before any1265"1.0-rcX" tags. The placement of the main release tag relative to tags1266with various suffixes can be determined by specifying the empty suffix1267among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and1268"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags1269are listed first, followed by "v4.8", then "v4.8-ckX" and finally1270"v4.8-bfsX".1271+1272If more than one suffixes match the same tagname, then that tagname will1273be sorted according to the suffix which starts at the earliest position in1274the tagname. If more than one different matching suffixes start at1275that earliest position, then that tagname will be sorted according to the1276longest of those suffixes.1277The sorting order between different suffixes is undefined if they are1278in multiple config files.12791280web.browser::1281 Specify a web browser that may be used by some commands.1282 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]1283 may use it.12841285worktree.guessRemote::1286 With `add`, if no branch argument, and neither of `-b` nor1287 `-B` nor `--detach` are given, the command defaults to1288 creating a new branch from HEAD. If `worktree.guessRemote` is1289 set to true, `worktree add` tries to find a remote-tracking1290 branch whose name uniquely matches the new branch name. If1291 such a branch exists, it is checked out and set as "upstream"1292 for the new branch. If no such match can be found, it falls1293 back to creating a new branch from the current HEAD.