Documentation/config.txt

   1 CONFIGURATION FILE
   2 ------------------
   3
   4 The Git configuration file contains a number of variables that affect
   5 the Git commands' behavior. The `.git/config` file in each repository
   6 is used to store the configuration for that repository, and
   7 `$HOME/.gitconfig` is used to store a per-user configuration as
   8 fallback values for the `.git/config` file. The file `/etc/gitconfig`
   9 can be used to store a system-wide default configuration.
  10
  11 The configuration variables are used by both the Git plumbing
  12 and the porcelains. The variables are divided into sections, wherein
  13 the fully qualified variable name of the variable itself is the last
  14 dot-separated segment and the section name is everything before the last
  15 dot. The variable names are case-insensitive, allow only alphanumeric
  16 characters and `-`, and must start with an alphabetic character.  Some
  17 variables may appear multiple times; we say then that the variable is
  18 multivalued.
  19
  20 Syntax
  21 ~~~~~~
  22
  23 The syntax is fairly flexible and permissive; whitespaces are mostly
  24 ignored.  The '#' and ';' characters begin comments to the end of line,
  25 blank lines are ignored.
  26
  27 The file consists of sections and variables.  A section begins with
  28 the name of the section in square brackets and continues until the next
  29 section begins.  Section names are case-insensitive.  Only alphanumeric
  30 characters, `-` and `.` are allowed in section names.  Each variable
  31 must belong to some section, which means that there must be a section
  32 header before the first setting of a variable.
  33
  34 Sections can be further divided into subsections.  To begin a subsection
  35 put its name in double quotes, separated by space from the section name,
  36 in the section header, like in the example below:
  37
  38 --------
  39         [section "subsection"]
  40
  41 --------
  42
  43 Subsection names are case sensitive and can contain any characters except
  44 newline and the null byte. Doublequote `"` and backslash can be included
  45 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
  46 other 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.
  48 Variables may belong directly to a section or to a given subsection. You
  49 can have `[section]` if you have `[section "subsection"]`, but you don't
  50 need to.
  51
  52 There is also a deprecated `[section.subsection]` syntax. With this
  53 syntax, the subsection name is converted to lower-case and is also
  54 compared case sensitively. These subsection names follow the same
  55 restrictions as section names.
  56
  57 All the other lines (and the remainder of the line after the section
  58 header) are recognized as setting variables, in the form
  59 'name = value' (or just 'name', which is a short-hand to say that
  60 the variable is the boolean "true").
  61 The variable names are case-insensitive, allow only alphanumeric characters
  62 and `-`, and must start with an alphabetic character.
  63
  64 A line that defines a value can be continued to the next line by
  65 ending it with a `\`; the backquote and the end-of-line are
  66 stripped.  Leading whitespaces after 'name =', the remainder of the
  67 line after the first comment character '#' or ';', and trailing
  68 whitespaces of the line are discarded unless they are enclosed in
  69 double quotes.  Internal whitespaces within the value are retained
  70 verbatim.
  71
  72 Inside double quotes, double quote `"` and backslash `\` characters
  73 must be escaped: use `\"` for `"` and `\\` for `\`.
  74
  75 The following escape sequences (beside `\"` and `\\`) are recognized:
  76 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
  77 and `\b` for backspace (BS).  Other char escape sequences (including octal
  78 escape sequences) are invalid.
  79
  80
  81 Includes
  82 ~~~~~~~~
  83
  84 The `include` and `includeIf` sections allow you to include config
  85 directives from another source. These sections behave identically to
  86 each other with the exception that `includeIf` sections may be ignored
  87 if their condition does not evaluate to true; see "Conditional includes"
  88 below.
  89
  90 You can include a config file from another by setting the special
  91 `include.path` (or `includeIf.*.path`) variable to the name of the file
  92 to be included. The variable takes a pathname as its value, and is
  93 subject to tilde expansion. These variables can be given multiple times.
  94
  95 The contents of the included file are inserted immediately, as if they
  96 had been found at the location of the include directive. If the value of the
  97 variable is a relative path, the path is considered to
  98 be relative to the configuration file in which the include directive
  99 was found.  See below for examples.
 100
 101 Conditional includes
 102 ~~~~~~~~~~~~~~~~~~~~
 103
 104 You can include a config file from another conditionally by setting a
 105 `includeIf.<condition>.path` variable to the name of the file to be
 106 included.
 107
 108 The condition starts with a keyword followed by a colon and some data
 109 whose format and meaning depends on the keyword. Supported keywords
 110 are:
 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 +
 118 The .git location may be auto-discovered, or come from `$GIT_DIR`
 119 environment variable. If the repository is auto discovered via a .git
 120 file (e.g. from submodules, or a linked worktree), the .git location
 121 would be the final location where the .git directory is, not where the
 122 .git file is.
 123 +
 124 The pattern can contain standard globbing wildcards and two additional
 125 ones, `**/` and `/**`, that can match multiple path components. Please
 126 refer 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
 146 A 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 +
 155 This was not the case in the initial release of this feature in
 156 v2.13.0, which only matched the realpath version. Configuration that
 157 wants to be compatible with the initial release of this feature needs
 158 to 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
 163 Example
 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
 208 Values
 209 ~~~~~~
 210
 211 Values of many variables are treated as a simple string, but there
 212 are variables that take values of specific types and there are rules
 213 as to how to spell them.
 214
 215 boolean::
 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 +
 228 When converting a value to its canonical form using the `--type=bool` type
 229 specifier, 'git config' will ensure that the output is "true" or
 230 "false" (spelled in lowercase).
 231
 232 integer::
 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
 237 color::
 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 +
 242 The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
 243 `blue`, `magenta`, `cyan` and `white`.  The first color given is the
 244 foreground; the second is the background.
 245 +
 246 Colors may also be given as numbers between 0 and 255; these use ANSI
 247 256-color mode (but note that not all terminals may support this).  If
 248 your terminal supports it, you may also specify 24-bit RGB values as
 249 hex, like `#ff0ab3`.
 250 +
 251 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
 252 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
 253 The position of any attributes with respect to the colors
 254 (before, after, or in between), doesn't matter. Specific attributes may
 255 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
 256 `no-ul`, etc).
 257 +
 258 An empty color string produces no color effect at all. This can be used
 259 to avoid coloring specific elements without disabling color entirely.
 260 +
 261 For git's pre-defined color slots, the attributes are meant to be reset
 262 at the beginning of each item in the colored output. So setting
 263 `color.decorate.branch` to `black` will paint that branch name in a
 264 plain `black`, even if the previous thing on the same output line (e.g.
 265 opening parenthesis before the list of branch names in `log --decorate`
 266 output) is set to be painted with `bold` or some other attribute.
 267 However, custom log formats may do more complicated and layered
 268 coloring, and the negated forms may be useful there.
 269
 270 pathname::
 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
 278 Variables
 279 ~~~~~~~~~
 280
 281 Note that this list is non-comprehensive and not necessarily complete.
 282 For command-specific variables, you will find a more detailed description
 283 in the appropriate manual page.
 284
 285 Other git-related tools may and do use their own variables.  When
 286 inventing new variables for use in your own tool, make sure their
 287 names do not conflict with those that are used by Git itself and
 288 other popular tools, and describe them in your documentation.
 289
 290 include::config/advice.txt[]
 291
 292 include::config/core.txt[]
 293
 294 include::config/add.txt[]
 295
 296 include::config/alias.txt[]
 297
 298 include::config/am.txt[]
 299
 300 include::config/apply.txt[]
 301
 302 include::config/blame.txt[]
 303
 304 include::config/branch.txt[]
 305
 306 include::config/browser.txt[]
 307
 308 include::config/checkout.txt[]
 309
 310 include::config/clean.txt[]
 311
 312 include::config/color.txt[]
 313
 314 include::config/column.txt[]
 315
 316 include::config/commit.txt[]
 317
 318 include::config/credential.txt[]
 319
 320 include::config/completion.txt[]
 321
 322 include::config/diff.txt[]
 323
 324 include::config/difftool.txt[]
 325
 326 include::config/fastimport.txt[]
 327
 328 include::config/fetch.txt[]
 329
 330 include::config/format.txt[]
 331
 332 include::config/filter.txt[]
 333
 334 include::config/fsck.txt[]
 335
 336 include::config/gc.txt[]
 337
 338 include::config/gitcvs.txt[]
 339
 340 include::config/gitweb.txt[]
 341
 342 include::config/grep.txt[]
 343
 344 include::config/gpg.txt[]
 345
 346 include::config/gui.txt[]
 347
 348 include::config/guitool.txt[]
 349
 350 include::config/help.txt[]
 351
 352 include::config/http.txt[]
 353
 354 include::config/i18n.txt[]
 355
 356 include::config/imap.txt[]
 357
 358 include::config/index.txt[]
 359
 360 include::config/init.txt[]
 361
 362 include::config/instaweb.txt[]
 363
 364 include::config/interactive.txt[]
 365
 366 include::config/log.txt[]
 367
 368 include::config/mailinfo.txt[]
 369
 370 include::config/mailmap.txt[]
 371
 372 include::config/man.txt[]
 373
 374 include::config/merge.txt[]
 375
 376 include::config/mergetool.txt[]
 377
 378 include::config/notes.txt[]
 379
 380 include::config/pack.txt[]
 381
 382 include::config/pager.txt[]
 383
 384 include::config/pretty.txt[]
 385
 386 include::config/protocol.txt[]
 387
 388 include::config/pull.txt[]
 389
 390 include::config/push.txt[]
 391
 392 include::config/rebase.txt[]
 393
 394 include::config/receive.txt[]
 395
 396 include::config/remote.txt[]
 397
 398 remotes.<group>::
 399         The list of remotes which are fetched by "git remote update
 400         <group>".  See linkgit:git-remote[1].
 401
 402 repack.useDeltaBaseOffset::
 403         By default, linkgit:git-repack[1] creates packs that use
 404         delta-base offset. If you need to share your repository with
 405         Git older than version 1.4.4, either directly or via a dumb
 406         protocol such as http, then you need to set this option to
 407         "false" and repack. Access from old Git versions over the
 408         native protocol are unaffected by this option.
 409
 410 repack.packKeptObjects::
 411         If set to true, makes `git repack` act as if
 412         `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
 413         details. Defaults to `false` normally, but `true` if a bitmap
 414         index is being written (either via `--write-bitmap-index` or
 415         `repack.writeBitmaps`).
 416
 417 repack.useDeltaIslands::
 418         If set to true, makes `git repack` act as if `--delta-islands`
 419         was passed. Defaults to `false`.
 420
 421 repack.writeBitmaps::
 422         When true, git will write a bitmap index when packing all
 423         objects to disk (e.g., when `git repack -a` is run).  This
 424         index can speed up the "counting objects" phase of subsequent
 425         packs created for clones and fetches, at the cost of some disk
 426         space and extra time spent on the initial repack.  This has
 427         no effect if multiple packfiles are created.
 428         Defaults to false.
 429
 430 rerere.autoUpdate::
 431         When set to true, `git-rerere` updates the index with the
 432         resulting contents after it cleanly resolves conflicts using
 433         previously recorded resolution.  Defaults to false.
 434
 435 rerere.enabled::
 436         Activate recording of resolved conflicts, so that identical
 437         conflict hunks can be resolved automatically, should they be
 438         encountered again.  By default, linkgit:git-rerere[1] is
 439         enabled if there is an `rr-cache` directory under the
 440         `$GIT_DIR`, e.g. if "rerere" was previously used in the
 441         repository.
 442
 443 reset.quiet::
 444         When set to true, 'git reset' will default to the '--quiet' option.
 445
 446 include::sendemail-config.txt[]
 447
 448 sequence.editor::
 449         Text editor used by `git rebase -i` for editing the rebase instruction file.
 450         The value is meant to be interpreted by the shell when it is used.
 451         It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
 452         When not configured the default commit message editor is used instead.
 453
 454 showBranch.default::
 455         The default set of branches for linkgit:git-show-branch[1].
 456         See linkgit:git-show-branch[1].
 457
 458 splitIndex.maxPercentChange::
 459         When the split index feature is used, this specifies the
 460         percent of entries the split index can contain compared to the
 461         total number of entries in both the split index and the shared
 462         index before a new shared index is written.
 463         The value should be between 0 and 100. If the value is 0 then
 464         a new shared index is always written, if it is 100 a new
 465         shared index is never written.
 466         By default the value is 20, so a new shared index is written
 467         if the number of entries in the split index would be greater
 468         than 20 percent of the total number of entries.
 469         See linkgit:git-update-index[1].
 470
 471 splitIndex.sharedIndexExpire::
 472         When the split index feature is used, shared index files that
 473         were not modified since the time this variable specifies will
 474         be removed when a new shared index file is created. The value
 475         "now" expires all entries immediately, and "never" suppresses
 476         expiration altogether.
 477         The default value is "2.weeks.ago".
 478         Note that a shared index file is considered modified (for the
 479         purpose of expiration) each time a new split-index file is
 480         either created based on it or read from it.
 481         See linkgit:git-update-index[1].
 482
 483 include::config/ssh.txt[]
 484
 485 status.relativePaths::
 486         By default, linkgit:git-status[1] shows paths relative to the
 487         current directory. Setting this variable to `false` shows paths
 488         relative to the repository root (this was the default for Git
 489         prior to v1.5.4).
 490
 491 status.short::
 492         Set to true to enable --short by default in linkgit:git-status[1].
 493         The option --no-short takes precedence over this variable.
 494
 495 status.branch::
 496         Set to true to enable --branch by default in linkgit:git-status[1].
 497         The option --no-branch takes precedence over this variable.
 498
 499 status.displayCommentPrefix::
 500         If set to true, linkgit:git-status[1] will insert a comment
 501         prefix before each output line (starting with
 502         `core.commentChar`, i.e. `#` by default). This was the
 503         behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
 504         Defaults to false.
 505
 506 status.renameLimit::
 507         The number of files to consider when performing rename detection
 508         in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
 509         the value of diff.renameLimit.
 510
 511 status.renames::
 512         Whether and how Git detects renames in linkgit:git-status[1] and
 513         linkgit:git-commit[1] .  If set to "false", rename detection is
 514         disabled. If set to "true", basic rename detection is enabled.
 515         If set to "copies" or "copy", Git will detect copies, as well.
 516         Defaults to the value of diff.renames.
 517
 518 status.showStash::
 519         If set to true, linkgit:git-status[1] will display the number of
 520         entries currently stashed away.
 521         Defaults to false.
 522
 523 status.showUntrackedFiles::
 524         By default, linkgit:git-status[1] and linkgit:git-commit[1] show
 525         files which are not currently tracked by Git. Directories which
 526         contain only untracked files, are shown with the directory name
 527         only. Showing untracked files means that Git needs to lstat() all
 528         the files in the whole repository, which might be slow on some
 529         systems. So, this variable controls how the commands displays
 530         the untracked files. Possible values are:
 531 +
 532 --
 533 * `no` - Show no untracked files.
 534 * `normal` - Show untracked files and directories.
 535 * `all` - Show also individual files in untracked directories.
 536 --
 537 +
 538 If this variable is not specified, it defaults to 'normal'.
 539 This variable can be overridden with the -u|--untracked-files option
 540 of linkgit:git-status[1] and linkgit:git-commit[1].
 541
 542 status.submoduleSummary::
 543         Defaults to false.
 544         If this is set to a non zero number or true (identical to -1 or an
 545         unlimited number), the submodule summary will be enabled and a
 546         summary of commits for modified submodules will be shown (see
 547         --summary-limit option of linkgit:git-submodule[1]). Please note
 548         that the summary output command will be suppressed for all
 549         submodules when `diff.ignoreSubmodules` is set to 'all' or only
 550         for those submodules where `submodule.<name>.ignore=all`. The only
 551         exception to that rule is that status and commit will show staged
 552         submodule changes. To
 553         also view the summary for ignored submodules you can either use
 554         the --ignore-submodules=dirty command-line option or the 'git
 555         submodule summary' command, which shows a similar output but does
 556         not honor these settings.
 557
 558 stash.showPatch::
 559         If this is set to true, the `git stash show` command without an
 560         option will show the stash entry in patch form.  Defaults to false.
 561         See description of 'show' command in linkgit:git-stash[1].
 562
 563 stash.showStat::
 564         If this is set to true, the `git stash show` command without an
 565         option will show diffstat of the stash entry.  Defaults to true.
 566         See description of 'show' command in linkgit:git-stash[1].
 567
 568 include::submodule-config.txt[]
 569
 570 tag.forceSignAnnotated::
 571         A boolean to specify whether annotated tags created should be GPG signed.
 572         If `--annotate` is specified on the command line, it takes
 573         precedence over this option.
 574
 575 tag.sort::
 576         This variable controls the sort ordering of tags when displayed by
 577         linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
 578         value of this variable will be used as the default.
 579
 580 tar.umask::
 581         This variable can be used to restrict the permission bits of
 582         tar archive entries.  The default is 0002, which turns off the
 583         world write bit.  The special value "user" indicates that the
 584         archiving user's umask will be used instead.  See umask(2) and
 585         linkgit:git-archive[1].
 586
 587 transfer.fsckObjects::
 588         When `fetch.fsckObjects` or `receive.fsckObjects` are
 589         not set, the value of this variable is used instead.
 590         Defaults to false.
 591 +
 592 When set, the fetch or receive will abort in the case of a malformed
 593 object or a link to a nonexistent object. In addition, various other
 594 issues are checked for, including legacy issues (see `fsck.<msg-id>`),
 595 and potential security issues like the existence of a `.GIT` directory
 596 or a malicious `.gitmodules` file (see the release notes for v2.2.1
 597 and v2.17.1 for details). Other sanity and security checks may be
 598 added in future releases.
 599 +
 600 On the receiving side, failing fsckObjects will make those objects
 601 unreachable, see "QUARANTINE ENVIRONMENT" in
 602 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
 603 instead be left unreferenced in the repository.
 604 +
 605 Due to the non-quarantine nature of the `fetch.fsckObjects`
 606 implementation it can not be relied upon to leave the object store
 607 clean like `receive.fsckObjects` can.
 608 +
 609 As objects are unpacked they're written to the object store, so there
 610 can be cases where malicious objects get introduced even though the
 611 "fetch" failed, only to have a subsequent "fetch" succeed because only
 612 new incoming objects are checked, not those that have already been
 613 written to the object store. That difference in behavior should not be
 614 relied upon. In the future, such objects may be quarantined for
 615 "fetch" as well.
 616 +
 617 For now, the paranoid need to find some way to emulate the quarantine
 618 environment if they'd like the same protection as "push". E.g. in the
 619 case of an internal mirror do the mirroring in two steps, one to fetch
 620 the untrusted objects, and then do a second "push" (which will use the
 621 quarantine) to another internal repo, and have internal clients
 622 consume this pushed-to repository, or embargo internal fetches and
 623 only allow them once a full "fsck" has run (and no new fetches have
 624 happened in the meantime).
 625
 626 transfer.hideRefs::
 627         String(s) `receive-pack` and `upload-pack` use to decide which
 628         refs to omit from their initial advertisements.  Use more than
 629         one definition to specify multiple prefix strings. A ref that is
 630         under the hierarchies listed in the value of this variable is
 631         excluded, and is hidden when responding to `git push` or `git
 632         fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
 633         program-specific versions of this config.
 634 +
 635 You may also include a `!` in front of the ref name to negate the entry,
 636 explicitly exposing it, even if an earlier entry marked it as hidden.
 637 If you have multiple hideRefs values, later entries override earlier ones
 638 (and entries in more-specific config files override less-specific ones).
 639 +
 640 If a namespace is in use, the namespace prefix is stripped from each
 641 reference before it is matched against `transfer.hiderefs` patterns.
 642 For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
 643 the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
 644 is omitted from the advertisements but `refs/heads/master` and
 645 `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
 646 "have" lines. In order to match refs before stripping, add a `^` in front of
 647 the ref name. If you combine `!` and `^`, `!` must be specified first.
 648 +
 649 Even if you hide refs, a client may still be able to steal the target
 650 objects via the techniques described in the "SECURITY" section of the
 651 linkgit:gitnamespaces[7] man page; it's best to keep private data in a
 652 separate repository.
 653
 654 transfer.unpackLimit::
 655         When `fetch.unpackLimit` or `receive.unpackLimit` are
 656         not set, the value of this variable is used instead.
 657         The default value is 100.
 658
 659 uploadarchive.allowUnreachable::
 660         If true, allow clients to use `git archive --remote` to request
 661         any tree, whether reachable from the ref tips or not. See the
 662         discussion in the "SECURITY" section of
 663         linkgit:git-upload-archive[1] for more details. Defaults to
 664         `false`.
 665
 666 uploadpack.hideRefs::
 667         This variable is the same as `transfer.hideRefs`, but applies
 668         only to `upload-pack` (and so affects only fetches, not pushes).
 669         An attempt to fetch a hidden ref by `git fetch` will fail.  See
 670         also `uploadpack.allowTipSHA1InWant`.
 671
 672 uploadpack.allowTipSHA1InWant::
 673         When `uploadpack.hideRefs` is in effect, allow `upload-pack`
 674         to accept a fetch request that asks for an object at the tip
 675         of a hidden ref (by default, such a request is rejected).
 676         See also `uploadpack.hideRefs`.  Even if this is false, a client
 677         may be able to steal objects via the techniques described in the
 678         "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
 679         best to keep private data in a separate repository.
 680
 681 uploadpack.allowReachableSHA1InWant::
 682         Allow `upload-pack` to accept a fetch request that asks for an
 683         object that is reachable from any ref tip. However, note that
 684         calculating object reachability is computationally expensive.
 685         Defaults to `false`.  Even if this is false, a client may be able
 686         to steal objects via the techniques described in the "SECURITY"
 687         section of the linkgit:gitnamespaces[7] man page; it's best to
 688         keep private data in a separate repository.
 689
 690 uploadpack.allowAnySHA1InWant::
 691         Allow `upload-pack` to accept a fetch request that asks for any
 692         object at all.
 693         Defaults to `false`.
 694
 695 uploadpack.keepAlive::
 696         When `upload-pack` has started `pack-objects`, there may be a
 697         quiet period while `pack-objects` prepares the pack. Normally
 698         it would output progress information, but if `--quiet` was used
 699         for the fetch, `pack-objects` will output nothing at all until
 700         the pack data begins. Some clients and networks may consider
 701         the server to be hung and give up. Setting this option instructs
 702         `upload-pack` to send an empty keepalive packet every
 703         `uploadpack.keepAlive` seconds. Setting this option to 0
 704         disables keepalive packets entirely. The default is 5 seconds.
 705
 706 uploadpack.packObjectsHook::
 707         If this option is set, when `upload-pack` would run
 708         `git pack-objects` to create a packfile for a client, it will
 709         run this shell command instead.  The `pack-objects` command and
 710         arguments it _would_ have run (including the `git pack-objects`
 711         at the beginning) are appended to the shell command. The stdin
 712         and stdout of the hook are treated as if `pack-objects` itself
 713         was run. I.e., `upload-pack` will feed input intended for
 714         `pack-objects` to the hook, and expects a completed packfile on
 715         stdout.
 716 +
 717 Note that this configuration variable is ignored if it is seen in the
 718 repository-level config (this is a safety measure against fetching from
 719 untrusted repositories).
 720
 721 uploadpack.allowFilter::
 722         If this option is set, `upload-pack` will support partial
 723         clone and partial fetch object filtering.
 724
 725 uploadpack.allowRefInWant::
 726         If this option is set, `upload-pack` will support the `ref-in-want`
 727         feature of the protocol version 2 `fetch` command.  This feature
 728         is intended for the benefit of load-balanced servers which may
 729         not have the same view of what OIDs their refs point to due to
 730         replication delay.
 731
 732 url.<base>.insteadOf::
 733         Any URL that starts with this value will be rewritten to
 734         start, instead, with <base>. In cases where some site serves a
 735         large number of repositories, and serves them with multiple
 736         access methods, and some users need to use different access
 737         methods, this feature allows people to specify any of the
 738         equivalent URLs and have Git automatically rewrite the URL to
 739         the best alternative for the particular user, even for a
 740         never-before-seen repository on the site.  When more than one
 741         insteadOf strings match a given URL, the longest match is used.
 742 +
 743 Note that any protocol restrictions will be applied to the rewritten
 744 URL. If the rewrite changes the URL to use a custom protocol or remote
 745 helper, you may need to adjust the `protocol.*.allow` config to permit
 746 the request.  In particular, protocols you expect to use for submodules
 747 must be set to `always` rather than the default of `user`. See the
 748 description of `protocol.allow` above.
 749
 750 url.<base>.pushInsteadOf::
 751         Any URL that starts with this value will not be pushed to;
 752         instead, it will be rewritten to start with <base>, and the
 753         resulting URL will be pushed to. In cases where some site serves
 754         a large number of repositories, and serves them with multiple
 755         access methods, some of which do not allow push, this feature
 756         allows people to specify a pull-only URL and have Git
 757         automatically use an appropriate URL to push, even for a
 758         never-before-seen repository on the site.  When more than one
 759         pushInsteadOf strings match a given URL, the longest match is
 760         used.  If a remote has an explicit pushurl, Git will ignore this
 761         setting for that remote.
 762
 763 user.email::
 764         Your email address to be recorded in any newly created commits.
 765         Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
 766         `EMAIL` environment variables.  See linkgit:git-commit-tree[1].
 767
 768 user.name::
 769         Your full name to be recorded in any newly created commits.
 770         Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
 771         environment variables.  See linkgit:git-commit-tree[1].
 772
 773 user.useConfigOnly::
 774         Instruct Git to avoid trying to guess defaults for `user.email`
 775         and `user.name`, and instead retrieve the values only from the
 776         configuration. For example, if you have multiple email addresses
 777         and would like to use a different one for each repository, then
 778         with this configuration option set to `true` in the global config
 779         along with a name, Git will prompt you to set up an email before
 780         making new commits in a newly cloned repository.
 781         Defaults to `false`.
 782
 783 user.signingKey::
 784         If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
 785         key you want it to automatically when creating a signed tag or
 786         commit, you can override the default selection with this variable.
 787         This option is passed unchanged to gpg's --local-user parameter,
 788         so you may specify a key using any method that gpg supports.
 789
 790 versionsort.prereleaseSuffix (deprecated)::
 791         Deprecated alias for `versionsort.suffix`.  Ignored if
 792         `versionsort.suffix` is set.
 793
 794 versionsort.suffix::
 795         Even when version sort is used in linkgit:git-tag[1], tagnames
 796         with the same base version but different suffixes are still sorted
 797         lexicographically, resulting e.g. in prerelease tags appearing
 798         after the main release (e.g. "1.0-rc1" after "1.0").  This
 799         variable can be specified to determine the sorting order of tags
 800         with different suffixes.
 801 +
 802 By specifying a single suffix in this variable, any tagname containing
 803 that suffix will appear before the corresponding main release.  E.g. if
 804 the variable is set to "-rc", then all "1.0-rcX" tags will appear before
 805 "1.0".  If specified multiple times, once per suffix, then the order of
 806 suffixes in the configuration will determine the sorting order of tagnames
 807 with those suffixes.  E.g. if "-pre" appears before "-rc" in the
 808 configuration, then all "1.0-preX" tags will be listed before any
 809 "1.0-rcX" tags.  The placement of the main release tag relative to tags
 810 with various suffixes can be determined by specifying the empty suffix
 811 among those other suffixes.  E.g. if the suffixes "-rc", "", "-ck" and
 812 "-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
 813 are listed first, followed by "v4.8", then "v4.8-ckX" and finally
 814 "v4.8-bfsX".
 815 +
 816 If more than one suffixes match the same tagname, then that tagname will
 817 be sorted according to the suffix which starts at the earliest position in
 818 the tagname.  If more than one different matching suffixes start at
 819 that earliest position, then that tagname will be sorted according to the
 820 longest of those suffixes.
 821 The sorting order between different suffixes is undefined if they are
 822 in multiple config files.
 823
 824 web.browser::
 825         Specify a web browser that may be used by some commands.
 826         Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
 827         may use it.
 828
 829 worktree.guessRemote::
 830         With `add`, if no branch argument, and neither of `-b` nor
 831         `-B` nor `--detach` are given, the command defaults to
 832         creating a new branch from HEAD.  If `worktree.guessRemote` is
 833         set to true, `worktree add` tries to find a remote-tracking
 834         branch whose name uniquely matches the new branch name.  If
 835         such a branch exists, it is checked out and set as "upstream"
 836         for the new branch.  If no such match can be found, it falls
 837         back to creating a new branch from the current HEAD.