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 364interactive.singleKey:: 365 In interactive commands, allow the user to provide one-letter 366 input with a single key (i.e., without hitting enter). 367 Currently this is used by the `--patch` mode of 368 linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1], 369 linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this 370 setting is silently ignored if portable keystroke input 371 is not available; requires the Perl module Term::ReadKey. 372 373interactive.diffFilter:: 374 When an interactive command (such as `git add --patch`) shows 375 a colorized diff, git will pipe the diff through the shell 376 command defined by this configuration variable. The command may 377 mark up the diff further for human consumption, provided that it 378 retains a one-to-one correspondence with the lines in the 379 original diff. Defaults to disabled (no filtering). 380 381log.abbrevCommit:: 382 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 383 linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may 384 override this option with `--no-abbrev-commit`. 385 386log.date:: 387 Set the default date-time mode for the 'log' command. 388 Setting a value for log.date is similar to using 'git log''s 389 `--date` option. See linkgit:git-log[1] for details. 390 391log.decorate:: 392 Print out the ref names of any commits that are shown by the log 393 command. If 'short' is specified, the ref name prefixes 'refs/heads/', 394 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is 395 specified, the full ref name (including prefix) will be printed. 396 If 'auto' is specified, then if the output is going to a terminal, 397 the ref names are shown as if 'short' were given, otherwise no ref 398 names are shown. This is the same as the `--decorate` option 399 of the `git log`. 400 401log.follow:: 402 If `true`, `git log` will act as if the `--follow` option was used when 403 a single <path> is given. This has the same limitations as `--follow`, 404 i.e. it cannot be used to follow multiple files and does not work well 405 on non-linear history. 406 407log.graphColors:: 408 A list of colors, separated by commas, that can be used to draw 409 history lines in `git log --graph`. 410 411log.showRoot:: 412 If true, the initial commit will be shown as a big creation event. 413 This is equivalent to a diff against an empty tree. 414 Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which 415 normally hide the root commit will now show it. True by default. 416 417log.showSignature:: 418 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 419 linkgit:git-whatchanged[1] assume `--show-signature`. 420 421log.mailmap:: 422 If true, makes linkgit:git-log[1], linkgit:git-show[1], and 423 linkgit:git-whatchanged[1] assume `--use-mailmap`. 424 425mailinfo.scissors:: 426 If true, makes linkgit:git-mailinfo[1] (and therefore 427 linkgit:git-am[1]) act by default as if the --scissors option 428 was provided on the command-line. When active, this features 429 removes everything from the message body before a scissors 430 line (i.e. consisting mainly of ">8", "8<" and "-"). 431 432mailmap.file:: 433 The location of an augmenting mailmap file. The default 434 mailmap, located in the root of the repository, is loaded 435 first, then the mailmap file pointed to by this variable. 436 The location of the mailmap file may be in a repository 437 subdirectory, or somewhere outside of the repository itself. 438 See linkgit:git-shortlog[1] and linkgit:git-blame[1]. 439 440mailmap.blob:: 441 Like `mailmap.file`, but consider the value as a reference to a 442 blob in the repository. If both `mailmap.file` and 443 `mailmap.blob` are given, both are parsed, with entries from 444 `mailmap.file` taking precedence. In a bare repository, this 445 defaults to `HEAD:.mailmap`. In a non-bare repository, it 446 defaults to empty. 447 448man.viewer:: 449 Specify the programs that may be used to display help in the 450 'man' format. See linkgit:git-help[1]. 451 452man.<tool>.cmd:: 453 Specify the command to invoke the specified man viewer. The 454 specified command is evaluated in shell with the man page 455 passed as argument. (See linkgit:git-help[1].) 456 457man.<tool>.path:: 458 Override the path for the given tool that may be used to 459 display help in the 'man' format. See linkgit:git-help[1]. 460 461include::merge-config.txt[] 462 463mergetool.<tool>.path:: 464 Override the path for the given tool. This is useful in case 465 your tool is not in the PATH. 466 467mergetool.<tool>.cmd:: 468 Specify the command to invoke the specified merge tool. The 469 specified command is evaluated in shell with the following 470 variables available: 'BASE' is the name of a temporary file 471 containing the common base of the files to be merged, if available; 472 'LOCAL' is the name of a temporary file containing the contents of 473 the file on the current branch; 'REMOTE' is the name of a temporary 474 file containing the contents of the file from the branch being 475 merged; 'MERGED' contains the name of the file to which the merge 476 tool should write the results of a successful merge. 477 478mergetool.<tool>.trustExitCode:: 479 For a custom merge command, specify whether the exit code of 480 the merge command can be used to determine whether the merge was 481 successful. If this is not set to true then the merge target file 482 timestamp is checked and the merge assumed to have been successful 483 if the file has been updated, otherwise the user is prompted to 484 indicate the success of the merge. 485 486mergetool.meld.hasOutput:: 487 Older versions of `meld` do not support the `--output` option. 488 Git will attempt to detect whether `meld` supports `--output` 489 by inspecting the output of `meld --help`. Configuring 490 `mergetool.meld.hasOutput` will make Git skip these checks and 491 use the configured value instead. Setting `mergetool.meld.hasOutput` 492 to `true` tells Git to unconditionally use the `--output` option, 493 and `false` avoids using `--output`. 494 495mergetool.keepBackup:: 496 After performing a merge, the original file with conflict markers 497 can be saved as a file with a `.orig` extension. If this variable 498 is set to `false` then this file is not preserved. Defaults to 499 `true` (i.e. keep the backup files). 500 501mergetool.keepTemporaries:: 502 When invoking a custom merge tool, Git uses a set of temporary 503 files to pass to the tool. If the tool returns an error and this 504 variable is set to `true`, then these temporary files will be 505 preserved, otherwise they will be removed after the tool has 506 exited. Defaults to `false`. 507 508mergetool.writeToTemp:: 509 Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of 510 conflicting files in the worktree by default. Git will attempt 511 to use a temporary directory for these files when set `true`. 512 Defaults to `false`. 513 514mergetool.prompt:: 515 Prompt before each invocation of the merge resolution program. 516 517notes.mergeStrategy:: 518 Which merge strategy to choose by default when resolving notes 519 conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or 520 `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" 521 section of linkgit:git-notes[1] for more information on each strategy. 522 523notes.<name>.mergeStrategy:: 524 Which merge strategy to choose when doing a notes merge into 525 refs/notes/<name>. This overrides the more general 526 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in 527 linkgit:git-notes[1] for more information on the available strategies. 528 529notes.displayRef:: 530 The (fully qualified) refname from which to show notes when 531 showing commit messages. The value of this variable can be set 532 to a glob, in which case notes from all matching refs will be 533 shown. You may also specify this configuration variable 534 several times. A warning will be issued for refs that do not 535 exist, but a glob that does not match any refs is silently 536 ignored. 537+ 538This setting can be overridden with the `GIT_NOTES_DISPLAY_REF` 539environment variable, which must be a colon separated list of refs or 540globs. 541+ 542The effective value of "core.notesRef" (possibly overridden by 543GIT_NOTES_REF) is also implicitly added to the list of refs to be 544displayed. 545 546notes.rewrite.<command>:: 547 When rewriting commits with <command> (currently `amend` or 548 `rebase`) and this variable is set to `true`, Git 549 automatically copies your notes from the original to the 550 rewritten commit. Defaults to `true`, but see 551 "notes.rewriteRef" below. 552 553notes.rewriteMode:: 554 When copying notes during a rewrite (see the 555 "notes.rewrite.<command>" option), determines what to do if 556 the target commit already has a note. Must be one of 557 `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. 558 Defaults to `concatenate`. 559+ 560This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` 561environment variable. 562 563notes.rewriteRef:: 564 When copying notes during a rewrite, specifies the (fully 565 qualified) ref whose notes should be copied. The ref may be a 566 glob, in which case notes in all matching refs will be copied. 567 You may also specify this configuration several times. 568+ 569Does not have a default value; you must configure this variable to 570enable note rewriting. Set it to `refs/notes/commits` to enable 571rewriting for the default commit notes. 572+ 573This setting can be overridden with the `GIT_NOTES_REWRITE_REF` 574environment variable, which must be a colon separated list of refs or 575globs. 576 577pack.window:: 578 The size of the window used by linkgit:git-pack-objects[1] when no 579 window size is given on the command line. Defaults to 10. 580 581pack.depth:: 582 The maximum delta depth used by linkgit:git-pack-objects[1] when no 583 maximum depth is given on the command line. Defaults to 50. 584 Maximum value is 4095. 585 586pack.windowMemory:: 587 The maximum size of memory that is consumed by each thread 588 in linkgit:git-pack-objects[1] for pack window memory when 589 no limit is given on the command line. The value can be 590 suffixed with "k", "m", or "g". When left unconfigured (or 591 set explicitly to 0), there will be no limit. 592 593pack.compression:: 594 An integer -1..9, indicating the compression level for objects 595 in a pack file. -1 is the zlib default. 0 means no 596 compression, and 1..9 are various speed/size tradeoffs, 9 being 597 slowest. If not set, defaults to core.compression. If that is 598 not set, defaults to -1, the zlib default, which is "a default 599 compromise between speed and compression (currently equivalent 600 to level 6)." 601+ 602Note that changing the compression level will not automatically recompress 603all existing objects. You can force recompression by passing the -F option 604to linkgit:git-repack[1]. 605 606pack.island:: 607 An extended regular expression configuring a set of delta 608 islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] 609 for details. 610 611pack.islandCore:: 612 Specify an island name which gets to have its objects be 613 packed first. This creates a kind of pseudo-pack at the front 614 of one pack, so that the objects from the specified island are 615 hopefully faster to copy into any pack that should be served 616 to a user requesting these objects. In practice this means 617 that the island specified should likely correspond to what is 618 the most commonly cloned in the repo. See also "DELTA ISLANDS" 619 in linkgit:git-pack-objects[1]. 620 621pack.deltaCacheSize:: 622 The maximum memory in bytes used for caching deltas in 623 linkgit:git-pack-objects[1] before writing them out to a pack. 624 This cache is used to speed up the writing object phase by not 625 having to recompute the final delta result once the best match 626 for all objects is found. Repacking large repositories on machines 627 which are tight with memory might be badly impacted by this though, 628 especially if this cache pushes the system into swapping. 629 A value of 0 means no limit. The smallest size of 1 byte may be 630 used to virtually disable this cache. Defaults to 256 MiB. 631 632pack.deltaCacheLimit:: 633 The maximum size of a delta, that is cached in 634 linkgit:git-pack-objects[1]. This cache is used to speed up the 635 writing object phase by not having to recompute the final delta 636 result once the best match for all objects is found. 637 Defaults to 1000. Maximum value is 65535. 638 639pack.threads:: 640 Specifies the number of threads to spawn when searching for best 641 delta matches. This requires that linkgit:git-pack-objects[1] 642 be compiled with pthreads otherwise this option is ignored with a 643 warning. This is meant to reduce packing time on multiprocessor 644 machines. The required amount of memory for the delta search window 645 is however multiplied by the number of threads. 646 Specifying 0 will cause Git to auto-detect the number of CPU's 647 and set the number of threads accordingly. 648 649pack.indexVersion:: 650 Specify the default pack index version. Valid values are 1 for 651 legacy pack index used by Git versions prior to 1.5.2, and 2 for 652 the new pack index with capabilities for packs larger than 4 GB 653 as well as proper protection against the repacking of corrupted 654 packs. Version 2 is the default. Note that version 2 is enforced 655 and this config option ignored whenever the corresponding pack is 656 larger than 2 GB. 657+ 658If you have an old Git that does not understand the version 2 `*.idx` file, 659cloning or fetching over a non native protocol (e.g. "http") 660that will copy both `*.pack` file and corresponding `*.idx` file from the 661other side may give you a repository that cannot be accessed with your 662older version of Git. If the `*.pack` file is smaller than 2 GB, however, 663you can use linkgit:git-index-pack[1] on the *.pack file to regenerate 664the `*.idx` file. 665 666pack.packSizeLimit:: 667 The maximum size of a pack. This setting only affects 668 packing to a file when repacking, i.e. the git:// protocol 669 is unaffected. It can be overridden by the `--max-pack-size` 670 option of linkgit:git-repack[1]. Reaching this limit results 671 in the creation of multiple packfiles; which in turn prevents 672 bitmaps from being created. 673 The minimum size allowed is limited to 1 MiB. 674 The default is unlimited. 675 Common unit suffixes of 'k', 'm', or 'g' are 676 supported. 677 678pack.useBitmaps:: 679 When true, git will use pack bitmaps (if available) when packing 680 to stdout (e.g., during the server side of a fetch). Defaults to 681 true. You should not generally need to turn this off unless 682 you are debugging pack bitmaps. 683 684pack.writeBitmaps (deprecated):: 685 This is a deprecated synonym for `repack.writeBitmaps`. 686 687pack.writeBitmapHashCache:: 688 When true, git will include a "hash cache" section in the bitmap 689 index (if one is written). This cache can be used to feed git's 690 delta heuristics, potentially leading to better deltas between 691 bitmapped and non-bitmapped objects (e.g., when serving a fetch 692 between an older, bitmapped pack and objects that have been 693 pushed since the last gc). The downside is that it consumes 4 694 bytes per object of disk space, and that JGit's bitmap 695 implementation does not understand it, causing it to complain if 696 Git and JGit are used on the same repository. Defaults to false. 697 698pager.<cmd>:: 699 If the value is boolean, turns on or off pagination of the 700 output of a particular Git subcommand when writing to a tty. 701 Otherwise, turns on pagination for the subcommand using the 702 pager specified by the value of `pager.<cmd>`. If `--paginate` 703 or `--no-pager` is specified on the command line, it takes 704 precedence over this option. To disable pagination for all 705 commands, set `core.pager` or `GIT_PAGER` to `cat`. 706 707pretty.<name>:: 708 Alias for a --pretty= format string, as specified in 709 linkgit:git-log[1]. Any aliases defined here can be used just 710 as the built-in pretty formats could. For example, 711 running `git config pretty.changelog "format:* %H %s"` 712 would cause the invocation `git log --pretty=changelog` 713 to be equivalent to running `git log "--pretty=format:* %H %s"`. 714 Note that an alias with the same name as a built-in format 715 will be silently ignored. 716 717protocol.allow:: 718 If set, provide a user defined default policy for all protocols which 719 don't explicitly have a policy (`protocol.<name>.allow`). By default, 720 if unset, known-safe protocols (http, https, git, ssh, file) have a 721 default policy of `always`, known-dangerous protocols (ext) have a 722 default policy of `never`, and all other protocols have a default 723 policy of `user`. Supported policies: 724+ 725-- 726 727* `always` - protocol is always able to be used. 728 729* `never` - protocol is never able to be used. 730 731* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is 732 either unset or has a value of 1. This policy should be used when you want a 733 protocol to be directly usable by the user but don't want it used by commands which 734 execute clone/fetch/push commands without user input, e.g. recursive 735 submodule initialization. 736 737-- 738 739protocol.<name>.allow:: 740 Set a policy to be used by protocol `<name>` with clone/fetch/push 741 commands. See `protocol.allow` above for the available policies. 742+ 743The protocol names currently used by git are: 744+ 745-- 746 - `file`: any local file-based path (including `file://` URLs, 747 or local paths) 748 749 - `git`: the anonymous git protocol over a direct TCP 750 connection (or proxy, if configured) 751 752 - `ssh`: git over ssh (including `host:path` syntax, 753 `ssh://`, etc). 754 755 - `http`: git over http, both "smart http" and "dumb http". 756 Note that this does _not_ include `https`; if you want to configure 757 both, you must do so individually. 758 759 - any external helpers are named by their protocol (e.g., use 760 `hg` to allow the `git-remote-hg` helper) 761-- 762 763protocol.version:: 764 Experimental. If set, clients will attempt to communicate with a 765 server using the specified protocol version. If unset, no 766 attempt will be made by the client to communicate using a 767 particular protocol version, this results in protocol version 0 768 being used. 769 Supported versions: 770+ 771-- 772 773* `0` - the original wire protocol. 774 775* `1` - the original wire protocol with the addition of a version string 776 in the initial response from the server. 777 778* `2` - link:technical/protocol-v2.html[wire protocol version 2]. 779 780-- 781 782include::pull-config.txt[] 783 784include::push-config.txt[] 785 786include::rebase-config.txt[] 787 788include::receive-config.txt[] 789 790remote.pushDefault:: 791 The remote to push to by default. Overrides 792 `branch.<name>.remote` for all branches, and is overridden by 793 `branch.<name>.pushRemote` for specific branches. 794 795remote.<name>.url:: 796 The URL of a remote repository. See linkgit:git-fetch[1] or 797 linkgit:git-push[1]. 798 799remote.<name>.pushurl:: 800 The push URL of a remote repository. See linkgit:git-push[1]. 801 802remote.<name>.proxy:: 803 For remotes that require curl (http, https and ftp), the URL to 804 the proxy to use for that remote. Set to the empty string to 805 disable proxying for that remote. 806 807remote.<name>.proxyAuthMethod:: 808 For remotes that require curl (http, https and ftp), the method to use for 809 authenticating against the proxy in use (probably set in 810 `remote.<name>.proxy`). See `http.proxyAuthMethod`. 811 812remote.<name>.fetch:: 813 The default set of "refspec" for linkgit:git-fetch[1]. See 814 linkgit:git-fetch[1]. 815 816remote.<name>.push:: 817 The default set of "refspec" for linkgit:git-push[1]. See 818 linkgit:git-push[1]. 819 820remote.<name>.mirror:: 821 If true, pushing to this remote will automatically behave 822 as if the `--mirror` option was given on the command line. 823 824remote.<name>.skipDefaultUpdate:: 825 If true, this remote will be skipped by default when updating 826 using linkgit:git-fetch[1] or the `update` subcommand of 827 linkgit:git-remote[1]. 828 829remote.<name>.skipFetchAll:: 830 If true, this remote will be skipped by default when updating 831 using linkgit:git-fetch[1] or the `update` subcommand of 832 linkgit:git-remote[1]. 833 834remote.<name>.receivepack:: 835 The default program to execute on the remote side when pushing. See 836 option --receive-pack of linkgit:git-push[1]. 837 838remote.<name>.uploadpack:: 839 The default program to execute on the remote side when fetching. See 840 option --upload-pack of linkgit:git-fetch-pack[1]. 841 842remote.<name>.tagOpt:: 843 Setting this value to --no-tags disables automatic tag following when 844 fetching from remote <name>. Setting it to --tags will fetch every 845 tag from remote <name>, even if they are not reachable from remote 846 branch heads. Passing these flags directly to linkgit:git-fetch[1] can 847 override this setting. See options --tags and --no-tags of 848 linkgit:git-fetch[1]. 849 850remote.<name>.vcs:: 851 Setting this to a value <vcs> will cause Git to interact with 852 the remote with the git-remote-<vcs> helper. 853 854remote.<name>.prune:: 855 When set to true, fetching from this remote by default will also 856 remove any remote-tracking references that no longer exist on the 857 remote (as if the `--prune` option was given on the command line). 858 Overrides `fetch.prune` settings, if any. 859 860remote.<name>.pruneTags:: 861 When set to true, fetching from this remote by default will also 862 remove any local tags that no longer exist on the remote if pruning 863 is activated in general via `remote.<name>.prune`, `fetch.prune` or 864 `--prune`. Overrides `fetch.pruneTags` settings, if any. 865+ 866See also `remote.<name>.prune` and the PRUNING section of 867linkgit:git-fetch[1]. 868 869remotes.<group>:: 870 The list of remotes which are fetched by "git remote update 871 <group>". See linkgit:git-remote[1]. 872 873repack.useDeltaBaseOffset:: 874 By default, linkgit:git-repack[1] creates packs that use 875 delta-base offset. If you need to share your repository with 876 Git older than version 1.4.4, either directly or via a dumb 877 protocol such as http, then you need to set this option to 878 "false" and repack. Access from old Git versions over the 879 native protocol are unaffected by this option. 880 881repack.packKeptObjects:: 882 If set to true, makes `git repack` act as if 883 `--pack-kept-objects` was passed. See linkgit:git-repack[1] for 884 details. Defaults to `false` normally, but `true` if a bitmap 885 index is being written (either via `--write-bitmap-index` or 886 `repack.writeBitmaps`). 887 888repack.useDeltaIslands:: 889 If set to true, makes `git repack` act as if `--delta-islands` 890 was passed. Defaults to `false`. 891 892repack.writeBitmaps:: 893 When true, git will write a bitmap index when packing all 894 objects to disk (e.g., when `git repack -a` is run). This 895 index can speed up the "counting objects" phase of subsequent 896 packs created for clones and fetches, at the cost of some disk 897 space and extra time spent on the initial repack. This has 898 no effect if multiple packfiles are created. 899 Defaults to false. 900 901rerere.autoUpdate:: 902 When set to true, `git-rerere` updates the index with the 903 resulting contents after it cleanly resolves conflicts using 904 previously recorded resolution. Defaults to false. 905 906rerere.enabled:: 907 Activate recording of resolved conflicts, so that identical 908 conflict hunks can be resolved automatically, should they be 909 encountered again. By default, linkgit:git-rerere[1] is 910 enabled if there is an `rr-cache` directory under the 911 `$GIT_DIR`, e.g. if "rerere" was previously used in the 912 repository. 913 914reset.quiet:: 915 When set to true, 'git reset' will default to the '--quiet' option. 916 917include::sendemail-config.txt[] 918 919sequence.editor:: 920 Text editor used by `git rebase -i` for editing the rebase instruction file. 921 The value is meant to be interpreted by the shell when it is used. 922 It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. 923 When not configured the default commit message editor is used instead. 924 925showBranch.default:: 926 The default set of branches for linkgit:git-show-branch[1]. 927 See linkgit:git-show-branch[1]. 928 929splitIndex.maxPercentChange:: 930 When the split index feature is used, this specifies the 931 percent of entries the split index can contain compared to the 932 total number of entries in both the split index and the shared 933 index before a new shared index is written. 934 The value should be between 0 and 100. If the value is 0 then 935 a new shared index is always written, if it is 100 a new 936 shared index is never written. 937 By default the value is 20, so a new shared index is written 938 if the number of entries in the split index would be greater 939 than 20 percent of the total number of entries. 940 See linkgit:git-update-index[1]. 941 942splitIndex.sharedIndexExpire:: 943 When the split index feature is used, shared index files that 944 were not modified since the time this variable specifies will 945 be removed when a new shared index file is created. The value 946 "now" expires all entries immediately, and "never" suppresses 947 expiration altogether. 948 The default value is "2.weeks.ago". 949 Note that a shared index file is considered modified (for the 950 purpose of expiration) each time a new split-index file is 951 either created based on it or read from it. 952 See linkgit:git-update-index[1]. 953 954include::config/ssh.txt[] 955 956status.relativePaths:: 957 By default, linkgit:git-status[1] shows paths relative to the 958 current directory. Setting this variable to `false` shows paths 959 relative to the repository root (this was the default for Git 960 prior to v1.5.4). 961 962status.short:: 963 Set to true to enable --short by default in linkgit:git-status[1]. 964 The option --no-short takes precedence over this variable. 965 966status.branch:: 967 Set to true to enable --branch by default in linkgit:git-status[1]. 968 The option --no-branch takes precedence over this variable. 969 970status.displayCommentPrefix:: 971 If set to true, linkgit:git-status[1] will insert a comment 972 prefix before each output line (starting with 973 `core.commentChar`, i.e. `#` by default). This was the 974 behavior of linkgit:git-status[1] in Git 1.8.4 and previous. 975 Defaults to false. 976 977status.renameLimit:: 978 The number of files to consider when performing rename detection 979 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to 980 the value of diff.renameLimit. 981 982status.renames:: 983 Whether and how Git detects renames in linkgit:git-status[1] and 984 linkgit:git-commit[1] . If set to "false", rename detection is 985 disabled. If set to "true", basic rename detection is enabled. 986 If set to "copies" or "copy", Git will detect copies, as well. 987 Defaults to the value of diff.renames. 988 989status.showStash:: 990 If set to true, linkgit:git-status[1] will display the number of 991 entries currently stashed away. 992 Defaults to false. 993 994status.showUntrackedFiles:: 995 By default, linkgit:git-status[1] and linkgit:git-commit[1] show 996 files which are not currently tracked by Git. Directories which 997 contain only untracked files, are shown with the directory name 998 only. Showing untracked files means that Git needs to lstat() all 999 the files in the whole repository, which might be slow on some1000 systems. So, this variable controls how the commands displays1001 the untracked files. Possible values are:1002+1003--1004* `no` - Show no untracked files.1005* `normal` - Show untracked files and directories.1006* `all` - Show also individual files in untracked directories.1007--1008+1009If this variable is not specified, it defaults to 'normal'.1010This variable can be overridden with the -u|--untracked-files option1011of linkgit:git-status[1] and linkgit:git-commit[1].10121013status.submoduleSummary::1014 Defaults to false.1015 If this is set to a non zero number or true (identical to -1 or an1016 unlimited number), the submodule summary will be enabled and a1017 summary of commits for modified submodules will be shown (see1018 --summary-limit option of linkgit:git-submodule[1]). Please note1019 that the summary output command will be suppressed for all1020 submodules when `diff.ignoreSubmodules` is set to 'all' or only1021 for those submodules where `submodule.<name>.ignore=all`. The only1022 exception to that rule is that status and commit will show staged1023 submodule changes. To1024 also view the summary for ignored submodules you can either use1025 the --ignore-submodules=dirty command-line option or the 'git1026 submodule summary' command, which shows a similar output but does1027 not honor these settings.10281029stash.showPatch::1030 If this is set to true, the `git stash show` command without an1031 option will show the stash entry in patch form. Defaults to false.1032 See description of 'show' command in linkgit:git-stash[1].10331034stash.showStat::1035 If this is set to true, the `git stash show` command without an1036 option will show diffstat of the stash entry. Defaults to true.1037 See description of 'show' command in linkgit:git-stash[1].10381039include::submodule-config.txt[]10401041tag.forceSignAnnotated::1042 A boolean to specify whether annotated tags created should be GPG signed.1043 If `--annotate` is specified on the command line, it takes1044 precedence over this option.10451046tag.sort::1047 This variable controls the sort ordering of tags when displayed by1048 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the1049 value of this variable will be used as the default.10501051tar.umask::1052 This variable can be used to restrict the permission bits of1053 tar archive entries. The default is 0002, which turns off the1054 world write bit. The special value "user" indicates that the1055 archiving user's umask will be used instead. See umask(2) and1056 linkgit:git-archive[1].10571058transfer.fsckObjects::1059 When `fetch.fsckObjects` or `receive.fsckObjects` are1060 not set, the value of this variable is used instead.1061 Defaults to false.1062+1063When set, the fetch or receive will abort in the case of a malformed1064object or a link to a nonexistent object. In addition, various other1065issues are checked for, including legacy issues (see `fsck.<msg-id>`),1066and potential security issues like the existence of a `.GIT` directory1067or a malicious `.gitmodules` file (see the release notes for v2.2.11068and v2.17.1 for details). Other sanity and security checks may be1069added in future releases.1070+1071On the receiving side, failing fsckObjects will make those objects1072unreachable, see "QUARANTINE ENVIRONMENT" in1073linkgit:git-receive-pack[1]. On the fetch side, malformed objects will1074instead be left unreferenced in the repository.1075+1076Due to the non-quarantine nature of the `fetch.fsckObjects`1077implementation it can not be relied upon to leave the object store1078clean like `receive.fsckObjects` can.1079+1080As objects are unpacked they're written to the object store, so there1081can be cases where malicious objects get introduced even though the1082"fetch" failed, only to have a subsequent "fetch" succeed because only1083new incoming objects are checked, not those that have already been1084written to the object store. That difference in behavior should not be1085relied upon. In the future, such objects may be quarantined for1086"fetch" as well.1087+1088For now, the paranoid need to find some way to emulate the quarantine1089environment if they'd like the same protection as "push". E.g. in the1090case of an internal mirror do the mirroring in two steps, one to fetch1091the untrusted objects, and then do a second "push" (which will use the1092quarantine) to another internal repo, and have internal clients1093consume this pushed-to repository, or embargo internal fetches and1094only allow them once a full "fsck" has run (and no new fetches have1095happened in the meantime).10961097transfer.hideRefs::1098 String(s) `receive-pack` and `upload-pack` use to decide which1099 refs to omit from their initial advertisements. Use more than1100 one definition to specify multiple prefix strings. A ref that is1101 under the hierarchies listed in the value of this variable is1102 excluded, and is hidden when responding to `git push` or `git1103 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for1104 program-specific versions of this config.1105+1106You may also include a `!` in front of the ref name to negate the entry,1107explicitly exposing it, even if an earlier entry marked it as hidden.1108If you have multiple hideRefs values, later entries override earlier ones1109(and entries in more-specific config files override less-specific ones).1110+1111If a namespace is in use, the namespace prefix is stripped from each1112reference before it is matched against `transfer.hiderefs` patterns.1113For example, if `refs/heads/master` is specified in `transfer.hideRefs` and1114the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`1115is omitted from the advertisements but `refs/heads/master` and1116`refs/namespaces/bar/refs/heads/master` are still advertised as so-called1117"have" lines. In order to match refs before stripping, add a `^` in front of1118the ref name. If you combine `!` and `^`, `!` must be specified first.1119+1120Even if you hide refs, a client may still be able to steal the target1121objects via the techniques described in the "SECURITY" section of the1122linkgit:gitnamespaces[7] man page; it's best to keep private data in a1123separate repository.11241125transfer.unpackLimit::1126 When `fetch.unpackLimit` or `receive.unpackLimit` are1127 not set, the value of this variable is used instead.1128 The default value is 100.11291130uploadarchive.allowUnreachable::1131 If true, allow clients to use `git archive --remote` to request1132 any tree, whether reachable from the ref tips or not. See the1133 discussion in the "SECURITY" section of1134 linkgit:git-upload-archive[1] for more details. Defaults to1135 `false`.11361137uploadpack.hideRefs::1138 This variable is the same as `transfer.hideRefs`, but applies1139 only to `upload-pack` (and so affects only fetches, not pushes).1140 An attempt to fetch a hidden ref by `git fetch` will fail. See1141 also `uploadpack.allowTipSHA1InWant`.11421143uploadpack.allowTipSHA1InWant::1144 When `uploadpack.hideRefs` is in effect, allow `upload-pack`1145 to accept a fetch request that asks for an object at the tip1146 of a hidden ref (by default, such a request is rejected).1147 See also `uploadpack.hideRefs`. Even if this is false, a client1148 may be able to steal objects via the techniques described in the1149 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's1150 best to keep private data in a separate repository.11511152uploadpack.allowReachableSHA1InWant::1153 Allow `upload-pack` to accept a fetch request that asks for an1154 object that is reachable from any ref tip. However, note that1155 calculating object reachability is computationally expensive.1156 Defaults to `false`. Even if this is false, a client may be able1157 to steal objects via the techniques described in the "SECURITY"1158 section of the linkgit:gitnamespaces[7] man page; it's best to1159 keep private data in a separate repository.11601161uploadpack.allowAnySHA1InWant::1162 Allow `upload-pack` to accept a fetch request that asks for any1163 object at all.1164 Defaults to `false`.11651166uploadpack.keepAlive::1167 When `upload-pack` has started `pack-objects`, there may be a1168 quiet period while `pack-objects` prepares the pack. Normally1169 it would output progress information, but if `--quiet` was used1170 for the fetch, `pack-objects` will output nothing at all until1171 the pack data begins. Some clients and networks may consider1172 the server to be hung and give up. Setting this option instructs1173 `upload-pack` to send an empty keepalive packet every1174 `uploadpack.keepAlive` seconds. Setting this option to 01175 disables keepalive packets entirely. The default is 5 seconds.11761177uploadpack.packObjectsHook::1178 If this option is set, when `upload-pack` would run1179 `git pack-objects` to create a packfile for a client, it will1180 run this shell command instead. The `pack-objects` command and1181 arguments it _would_ have run (including the `git pack-objects`1182 at the beginning) are appended to the shell command. The stdin1183 and stdout of the hook are treated as if `pack-objects` itself1184 was run. I.e., `upload-pack` will feed input intended for1185 `pack-objects` to the hook, and expects a completed packfile on1186 stdout.1187+1188Note that this configuration variable is ignored if it is seen in the1189repository-level config (this is a safety measure against fetching from1190untrusted repositories).11911192uploadpack.allowFilter::1193 If this option is set, `upload-pack` will support partial1194 clone and partial fetch object filtering.11951196uploadpack.allowRefInWant::1197 If this option is set, `upload-pack` will support the `ref-in-want`1198 feature of the protocol version 2 `fetch` command. This feature1199 is intended for the benefit of load-balanced servers which may1200 not have the same view of what OIDs their refs point to due to1201 replication delay.12021203url.<base>.insteadOf::1204 Any URL that starts with this value will be rewritten to1205 start, instead, with <base>. In cases where some site serves a1206 large number of repositories, and serves them with multiple1207 access methods, and some users need to use different access1208 methods, this feature allows people to specify any of the1209 equivalent URLs and have Git automatically rewrite the URL to1210 the best alternative for the particular user, even for a1211 never-before-seen repository on the site. When more than one1212 insteadOf strings match a given URL, the longest match is used.1213+1214Note that any protocol restrictions will be applied to the rewritten1215URL. If the rewrite changes the URL to use a custom protocol or remote1216helper, you may need to adjust the `protocol.*.allow` config to permit1217the request. In particular, protocols you expect to use for submodules1218must be set to `always` rather than the default of `user`. See the1219description of `protocol.allow` above.12201221url.<base>.pushInsteadOf::1222 Any URL that starts with this value will not be pushed to;1223 instead, it will be rewritten to start with <base>, and the1224 resulting URL will be pushed to. In cases where some site serves1225 a large number of repositories, and serves them with multiple1226 access methods, some of which do not allow push, this feature1227 allows people to specify a pull-only URL and have Git1228 automatically use an appropriate URL to push, even for a1229 never-before-seen repository on the site. When more than one1230 pushInsteadOf strings match a given URL, the longest match is1231 used. If a remote has an explicit pushurl, Git will ignore this1232 setting for that remote.12331234user.email::1235 Your email address to be recorded in any newly created commits.1236 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and1237 `EMAIL` environment variables. See linkgit:git-commit-tree[1].12381239user.name::1240 Your full name to be recorded in any newly created commits.1241 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`1242 environment variables. See linkgit:git-commit-tree[1].12431244user.useConfigOnly::1245 Instruct Git to avoid trying to guess defaults for `user.email`1246 and `user.name`, and instead retrieve the values only from the1247 configuration. For example, if you have multiple email addresses1248 and would like to use a different one for each repository, then1249 with this configuration option set to `true` in the global config1250 along with a name, Git will prompt you to set up an email before1251 making new commits in a newly cloned repository.1252 Defaults to `false`.12531254user.signingKey::1255 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the1256 key you want it to automatically when creating a signed tag or1257 commit, you can override the default selection with this variable.1258 This option is passed unchanged to gpg's --local-user parameter,1259 so you may specify a key using any method that gpg supports.12601261versionsort.prereleaseSuffix (deprecated)::1262 Deprecated alias for `versionsort.suffix`. Ignored if1263 `versionsort.suffix` is set.12641265versionsort.suffix::1266 Even when version sort is used in linkgit:git-tag[1], tagnames1267 with the same base version but different suffixes are still sorted1268 lexicographically, resulting e.g. in prerelease tags appearing1269 after the main release (e.g. "1.0-rc1" after "1.0"). This1270 variable can be specified to determine the sorting order of tags1271 with different suffixes.1272+1273By specifying a single suffix in this variable, any tagname containing1274that suffix will appear before the corresponding main release. E.g. if1275the variable is set to "-rc", then all "1.0-rcX" tags will appear before1276"1.0". If specified multiple times, once per suffix, then the order of1277suffixes in the configuration will determine the sorting order of tagnames1278with those suffixes. E.g. if "-pre" appears before "-rc" in the1279configuration, then all "1.0-preX" tags will be listed before any1280"1.0-rcX" tags. The placement of the main release tag relative to tags1281with various suffixes can be determined by specifying the empty suffix1282among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and1283"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags1284are listed first, followed by "v4.8", then "v4.8-ckX" and finally1285"v4.8-bfsX".1286+1287If more than one suffixes match the same tagname, then that tagname will1288be sorted according to the suffix which starts at the earliest position in1289the tagname. If more than one different matching suffixes start at1290that earliest position, then that tagname will be sorted according to the1291longest of those suffixes.1292The sorting order between different suffixes is undefined if they are1293in multiple config files.12941295web.browser::1296 Specify a web browser that may be used by some commands.1297 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]1298 may use it.12991300worktree.guessRemote::1301 With `add`, if no branch argument, and neither of `-b` nor1302 `-B` nor `--detach` are given, the command defaults to1303 creating a new branch from HEAD. If `worktree.guessRemote` is1304 set to true, `worktree add` tries to find a remote-tracking1305 branch whose name uniquely matches the new branch name. If1306 such a branch exists, it is checked out and set as "upstream"1307 for the new branch. If no such match can be found, it falls1308 back to creating a new branch from the current HEAD.