763bb291e5654a70bde829156b55f61fe2f83b5a
   1CONFIGURATION FILE
   2------------------
   3
   4The Git configuration file contains a number of variables that affect
   5the Git commands' behavior. The `.git/config` file in each repository
   6is used to store the configuration for that repository, and
   7`$HOME/.gitconfig` is used to store a per-user configuration as
   8fallback values for the `.git/config` file. The file `/etc/gitconfig`
   9can be used to store a system-wide default configuration.
  10
  11The configuration variables are used by both the Git plumbing
  12and the porcelains. The variables are divided into sections, wherein
  13the fully qualified variable name of the variable itself is the last
  14dot-separated segment and the section name is everything before the last
  15dot. The variable names are case-insensitive, allow only alphanumeric
  16characters and `-`, and must start with an alphabetic character.  Some
  17variables may appear multiple times; we say then that the variable is
  18multivalued.
  19
  20Syntax
  21~~~~~~
  22
  23The syntax is fairly flexible and permissive; whitespaces are mostly
  24ignored.  The '#' and ';' characters begin comments to the end of line,
  25blank lines are ignored.
  26
  27The file consists of sections and variables.  A section begins with
  28the name of the section in square brackets and continues until the next
  29section begins.  Section names are case-insensitive.  Only alphanumeric
  30characters, `-` and `.` are allowed in section names.  Each variable
  31must belong to some section, which means that there must be a section
  32header before the first setting of a variable.
  33
  34Sections can be further divided into subsections.  To begin a subsection
  35put its name in double quotes, separated by space from the section name,
  36in the section header, like in the example below:
  37
  38--------
  39        [section "subsection"]
  40
  41--------
  42
  43Subsection names are case sensitive and can contain any characters except
  44newline and the null byte. Doublequote `"` and backslash can be included
  45by escaping them as `\"` and `\\`, respectively. Backslashes preceding
  46other characters are dropped when reading; for example, `\t` is read as
  47`t` and `\0` is read as `0` Section headers cannot span multiple lines.
  48Variables may belong directly to a section or to a given subsection. You
  49can have `[section]` if you have `[section "subsection"]`, but you don't
  50need to.
  51
  52There is also a deprecated `[section.subsection]` syntax. With this
  53syntax, the subsection name is converted to lower-case and is also
  54compared case sensitively. These subsection names follow the same
  55restrictions as section names.
  56
  57All the other lines (and the remainder of the line after the section
  58header) are recognized as setting variables, in the form
  59'name = value' (or just 'name', which is a short-hand to say that
  60the variable is the boolean "true").
  61The variable names are case-insensitive, allow only alphanumeric characters
  62and `-`, and must start with an alphabetic character.
  63
  64A line that defines a value can be continued to the next line by
  65ending it with a `\`; the backquote and the end-of-line are
  66stripped.  Leading whitespaces after 'name =', the remainder of the
  67line after the first comment character '#' or ';', and trailing
  68whitespaces of the line are discarded unless they are enclosed in
  69double quotes.  Internal whitespaces within the value are retained
  70verbatim.
  71
  72Inside double quotes, double quote `"` and backslash `\` characters
  73must be escaped: use `\"` for `"` and `\\` for `\`.
  74
  75The following escape sequences (beside `\"` and `\\`) are recognized:
  76`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
  77and `\b` for backspace (BS).  Other char escape sequences (including octal
  78escape sequences) are invalid.
  79
  80
  81Includes
  82~~~~~~~~
  83
  84The `include` and `includeIf` sections allow you to include config
  85directives from another source. These sections behave identically to
  86each other with the exception that `includeIf` sections may be ignored
  87if their condition does not evaluate to true; see "Conditional includes"
  88below.
  89
  90You can include a config file from another by setting the special
  91`include.path` (or `includeIf.*.path`) variable to the name of the file
  92to be included. The variable takes a pathname as its value, and is
  93subject to tilde expansion. These variables can be given multiple times.
  94
  95The contents of the included file are inserted immediately, as if they
  96had been found at the location of the include directive. If the value of the
  97variable is a relative path, the path is considered to
  98be relative to the configuration file in which the include directive
  99was found.  See below for examples.
 100
 101Conditional includes
 102~~~~~~~~~~~~~~~~~~~~
 103
 104You can include a config file from another conditionally by setting a
 105`includeIf.<condition>.path` variable to the name of the file to be
 106included.
 107
 108The condition starts with a keyword followed by a colon and some data
 109whose format and meaning depends on the keyword. Supported keywords
 110are:
 111
 112`gitdir`::
 113
 114        The data that follows the keyword `gitdir:` is used as a glob
 115        pattern. If the location of the .git directory matches the
 116        pattern, the include condition is met.
 117+
 118The .git location may be auto-discovered, or come from `$GIT_DIR`
 119environment variable. If the repository is auto discovered via a .git
 120file (e.g. from submodules, or a linked worktree), the .git location
 121would be the final location where the .git directory is, not where the
 122.git file is.
 123+
 124The pattern can contain standard globbing wildcards and two additional
 125ones, `**/` and `/**`, that can match multiple path components. Please
 126refer to linkgit:gitignore[5] for details. For convenience:
 127
 128 * If the pattern starts with `~/`, `~` will be substituted with the
 129   content of the environment variable `HOME`.
 130
 131 * If the pattern starts with `./`, it is replaced with the directory
 132   containing the current config file.
 133
 134 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
 135   will be automatically prepended. For example, the pattern `foo/bar`
 136   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
 137
 138 * If the pattern ends with `/`, `**` will be automatically added. For
 139   example, the pattern `foo/` becomes `foo/**`. In other words, it
 140   matches "foo" and everything inside, recursively.
 141
 142`gitdir/i`::
 143        This is the same as `gitdir` except that matching is done
 144        case-insensitively (e.g. on case-insensitive file sytems)
 145
 146A few more notes on matching via `gitdir` and `gitdir/i`:
 147
 148 * Symlinks in `$GIT_DIR` are not resolved before matching.
 149
 150 * Both the symlink & realpath versions of paths will be matched
 151   outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
 152   /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
 153   will match.
 154+
 155This was not the case in the initial release of this feature in
 156v2.13.0, which only matched the realpath version. Configuration that
 157wants to be compatible with the initial release of this feature needs
 158to either specify only the realpath version, or both versions.
 159
 160 * Note that "../" is not special and will match literally, which is
 161   unlikely what you want.
 162
 163Example
 164~~~~~~~
 165
 166        # Core variables
 167        [core]
 168                ; Don't trust file modes
 169                filemode = false
 170
 171        # Our diff algorithm
 172        [diff]
 173                external = /usr/local/bin/diff-wrapper
 174                renames = true
 175
 176        [branch "devel"]
 177                remote = origin
 178                merge = refs/heads/devel
 179
 180        # Proxy settings
 181        [core]
 182                gitProxy="ssh" for "kernel.org"
 183                gitProxy=default-proxy ; for the rest
 184
 185        [include]
 186                path = /path/to/foo.inc ; include by absolute path
 187                path = foo.inc ; find "foo.inc" relative to the current file
 188                path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
 189
 190        ; include if $GIT_DIR is /path/to/foo/.git
 191        [includeIf "gitdir:/path/to/foo/.git"]
 192                path = /path/to/foo.inc
 193
 194        ; include for all repositories inside /path/to/group
 195        [includeIf "gitdir:/path/to/group/"]
 196                path = /path/to/foo.inc
 197
 198        ; include for all repositories inside $HOME/to/group
 199        [includeIf "gitdir:~/to/group/"]
 200                path = /path/to/foo.inc
 201
 202        ; relative paths are always relative to the including
 203        ; file (if the condition is true); their location is not
 204        ; affected by the condition
 205        [includeIf "gitdir:/path/to/group/"]
 206                path = foo.inc
 207
 208Values
 209~~~~~~
 210
 211Values of many variables are treated as a simple string, but there
 212are variables that take values of specific types and there are rules
 213as to how to spell them.
 214
 215boolean::
 216
 217       When a variable is said to take a boolean value, many
 218       synonyms are accepted for 'true' and 'false'; these are all
 219       case-insensitive.
 220
 221        true;; Boolean true literals are `yes`, `on`, `true`,
 222                and `1`.  Also, a variable defined without `= <value>`
 223                is taken as true.
 224
 225        false;; Boolean false literals are `no`, `off`, `false`,
 226                `0` and the empty string.
 227+
 228When converting a value to its canonical form using the `--type=bool` type
 229specifier, 'git config' will ensure that the output is "true" or
 230"false" (spelled in lowercase).
 231
 232integer::
 233       The value for many variables that specify various sizes can
 234       be suffixed with `k`, `M`,... to mean "scale the number by
 235       1024", "by 1024x1024", etc.
 236
 237color::
 238       The value for a variable that takes a color is a list of
 239       colors (at most two, one for foreground and one for background)
 240       and attributes (as many as you want), separated by spaces.
 241+
 242The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
 243`blue`, `magenta`, `cyan` and `white`.  The first color given is the
 244foreground; the second is the background.
 245+
 246Colors may also be given as numbers between 0 and 255; these use ANSI
 247256-color mode (but note that not all terminals may support this).  If
 248your terminal supports it, you may also specify 24-bit RGB values as
 249hex, like `#ff0ab3`.
 250+
 251The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
 252`italic`, and `strike` (for crossed-out or "strikethrough" letters).
 253The position of any attributes with respect to the colors
 254(before, after, or in between), doesn't matter. Specific attributes may
 255be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
 256`no-ul`, etc).
 257+
 258An empty color string produces no color effect at all. This can be used
 259to avoid coloring specific elements without disabling color entirely.
 260+
 261For git's pre-defined color slots, the attributes are meant to be reset
 262at the beginning of each item in the colored output. So setting
 263`color.decorate.branch` to `black` will paint that branch name in a
 264plain `black`, even if the previous thing on the same output line (e.g.
 265opening parenthesis before the list of branch names in `log --decorate`
 266output) is set to be painted with `bold` or some other attribute.
 267However, custom log formats may do more complicated and layered
 268coloring, and the negated forms may be useful there.
 269
 270pathname::
 271        A variable that takes a pathname value can be given a
 272        string that begins with "`~/`" or "`~user/`", and the usual
 273        tilde expansion happens to such a string: `~/`
 274        is expanded to the value of `$HOME`, and `~user/` to the
 275        specified user's home directory.
 276
 277
 278Variables
 279~~~~~~~~~
 280
 281Note that this list is non-comprehensive and not necessarily complete.
 282For command-specific variables, you will find a more detailed description
 283in the appropriate manual page.
 284
 285Other git-related tools may and do use their own variables.  When
 286inventing new variables for use in your own tool, make sure their
 287names do not conflict with those that are used by Git itself and
 288other popular tools, and describe them in your documentation.
 289
 290include::config/advice.txt[]
 291
 292include::config/core.txt[]
 293
 294include::config/add.txt[]
 295
 296include::config/alias.txt[]
 297
 298include::config/am.txt[]
 299
 300include::config/apply.txt[]
 301
 302include::config/blame.txt[]
 303
 304include::config/branch.txt[]
 305
 306include::config/browser.txt[]
 307
 308include::config/checkout.txt[]
 309
 310include::config/clean.txt[]
 311
 312include::config/color.txt[]
 313
 314include::config/column.txt[]
 315
 316include::config/commit.txt[]
 317
 318include::config/credential.txt[]
 319
 320include::config/completion.txt[]
 321
 322include::config/diff.txt[]
 323
 324include::config/difftool.txt[]
 325
 326include::config/fastimport.txt[]
 327
 328include::config/fetch.txt[]
 329
 330include::config/format.txt[]
 331
 332include::config/filter.txt[]
 333
 334include::config/fsck.txt[]
 335
 336include::config/gc.txt[]
 337
 338include::config/gitcvs.txt[]
 339
 340include::config/gitweb.txt[]
 341
 342include::config/grep.txt[]
 343
 344include::config/gpg.txt[]
 345
 346include::config/gui.txt[]
 347
 348include::config/guitool.txt[]
 349
 350include::config/help.txt[]
 351
 352include::config/http.txt[]
 353
 354include::config/i18n.txt[]
 355
 356include::config/imap.txt[]
 357
 358include::config/index.txt[]
 359
 360include::config/init.txt[]
 361
 362include::config/instaweb.txt[]
 363
 364include::config/interactive.txt[]
 365
 366log.abbrevCommit::
 367        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
 368        linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
 369        override this option with `--no-abbrev-commit`.
 370
 371log.date::
 372        Set the default date-time mode for the 'log' command.
 373        Setting a value for log.date is similar to using 'git log''s
 374        `--date` option.  See linkgit:git-log[1] for details.
 375
 376log.decorate::
 377        Print out the ref names of any commits that are shown by the log
 378        command. If 'short' is specified, the ref name prefixes 'refs/heads/',
 379        'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
 380        specified, the full ref name (including prefix) will be printed.
 381        If 'auto' is specified, then if the output is going to a terminal,
 382        the ref names are shown as if 'short' were given, otherwise no ref
 383        names are shown. This is the same as the `--decorate` option
 384        of the `git log`.
 385
 386log.follow::
 387        If `true`, `git log` will act as if the `--follow` option was used when
 388        a single <path> is given.  This has the same limitations as `--follow`,
 389        i.e. it cannot be used to follow multiple files and does not work well
 390        on non-linear history.
 391
 392log.graphColors::
 393        A list of colors, separated by commas, that can be used to draw
 394        history lines in `git log --graph`.
 395
 396log.showRoot::
 397        If true, the initial commit will be shown as a big creation event.
 398        This is equivalent to a diff against an empty tree.
 399        Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
 400        normally hide the root commit will now show it. True by default.
 401
 402log.showSignature::
 403        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
 404        linkgit:git-whatchanged[1] assume `--show-signature`.
 405
 406log.mailmap::
 407        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
 408        linkgit:git-whatchanged[1] assume `--use-mailmap`.
 409
 410mailinfo.scissors::
 411        If true, makes linkgit:git-mailinfo[1] (and therefore
 412        linkgit:git-am[1]) act by default as if the --scissors option
 413        was provided on the command-line. When active, this features
 414        removes everything from the message body before a scissors
 415        line (i.e. consisting mainly of ">8", "8<" and "-").
 416
 417mailmap.file::
 418        The location of an augmenting mailmap file. The default
 419        mailmap, located in the root of the repository, is loaded
 420        first, then the mailmap file pointed to by this variable.
 421        The location of the mailmap file may be in a repository
 422        subdirectory, or somewhere outside of the repository itself.
 423        See linkgit:git-shortlog[1] and linkgit:git-blame[1].
 424
 425mailmap.blob::
 426        Like `mailmap.file`, but consider the value as a reference to a
 427        blob in the repository. If both `mailmap.file` and
 428        `mailmap.blob` are given, both are parsed, with entries from
 429        `mailmap.file` taking precedence. In a bare repository, this
 430        defaults to `HEAD:.mailmap`. In a non-bare repository, it
 431        defaults to empty.
 432
 433man.viewer::
 434        Specify the programs that may be used to display help in the
 435        'man' format. See linkgit:git-help[1].
 436
 437man.<tool>.cmd::
 438        Specify the command to invoke the specified man viewer. The
 439        specified command is evaluated in shell with the man page
 440        passed as argument. (See linkgit:git-help[1].)
 441
 442man.<tool>.path::
 443        Override the path for the given tool that may be used to
 444        display help in the 'man' format. See linkgit:git-help[1].
 445
 446include::merge-config.txt[]
 447
 448mergetool.<tool>.path::
 449        Override the path for the given tool.  This is useful in case
 450        your tool is not in the PATH.
 451
 452mergetool.<tool>.cmd::
 453        Specify the command to invoke the specified merge tool.  The
 454        specified command is evaluated in shell with the following
 455        variables available: 'BASE' is the name of a temporary file
 456        containing the common base of the files to be merged, if available;
 457        'LOCAL' is the name of a temporary file containing the contents of
 458        the file on the current branch; 'REMOTE' is the name of a temporary
 459        file containing the contents of the file from the branch being
 460        merged; 'MERGED' contains the name of the file to which the merge
 461        tool should write the results of a successful merge.
 462
 463mergetool.<tool>.trustExitCode::
 464        For a custom merge command, specify whether the exit code of
 465        the merge command can be used to determine whether the merge was
 466        successful.  If this is not set to true then the merge target file
 467        timestamp is checked and the merge assumed to have been successful
 468        if the file has been updated, otherwise the user is prompted to
 469        indicate the success of the merge.
 470
 471mergetool.meld.hasOutput::
 472        Older versions of `meld` do not support the `--output` option.
 473        Git will attempt to detect whether `meld` supports `--output`
 474        by inspecting the output of `meld --help`.  Configuring
 475        `mergetool.meld.hasOutput` will make Git skip these checks and
 476        use the configured value instead.  Setting `mergetool.meld.hasOutput`
 477        to `true` tells Git to unconditionally use the `--output` option,
 478        and `false` avoids using `--output`.
 479
 480mergetool.keepBackup::
 481        After performing a merge, the original file with conflict markers
 482        can be saved as a file with a `.orig` extension.  If this variable
 483        is set to `false` then this file is not preserved.  Defaults to
 484        `true` (i.e. keep the backup files).
 485
 486mergetool.keepTemporaries::
 487        When invoking a custom merge tool, Git uses a set of temporary
 488        files to pass to the tool. If the tool returns an error and this
 489        variable is set to `true`, then these temporary files will be
 490        preserved, otherwise they will be removed after the tool has
 491        exited. Defaults to `false`.
 492
 493mergetool.writeToTemp::
 494        Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
 495        conflicting files in the worktree by default.  Git will attempt
 496        to use a temporary directory for these files when set `true`.
 497        Defaults to `false`.
 498
 499mergetool.prompt::
 500        Prompt before each invocation of the merge resolution program.
 501
 502notes.mergeStrategy::
 503        Which merge strategy to choose by default when resolving notes
 504        conflicts.  Must be one of `manual`, `ours`, `theirs`, `union`, or
 505        `cat_sort_uniq`.  Defaults to `manual`.  See "NOTES MERGE STRATEGIES"
 506        section of linkgit:git-notes[1] for more information on each strategy.
 507
 508notes.<name>.mergeStrategy::
 509        Which merge strategy to choose when doing a notes merge into
 510        refs/notes/<name>.  This overrides the more general
 511        "notes.mergeStrategy".  See the "NOTES MERGE STRATEGIES" section in
 512        linkgit:git-notes[1] for more information on the available strategies.
 513
 514notes.displayRef::
 515        The (fully qualified) refname from which to show notes when
 516        showing commit messages.  The value of this variable can be set
 517        to a glob, in which case notes from all matching refs will be
 518        shown.  You may also specify this configuration variable
 519        several times.  A warning will be issued for refs that do not
 520        exist, but a glob that does not match any refs is silently
 521        ignored.
 522+
 523This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
 524environment variable, which must be a colon separated list of refs or
 525globs.
 526+
 527The effective value of "core.notesRef" (possibly overridden by
 528GIT_NOTES_REF) is also implicitly added to the list of refs to be
 529displayed.
 530
 531notes.rewrite.<command>::
 532        When rewriting commits with <command> (currently `amend` or
 533        `rebase`) and this variable is set to `true`, Git
 534        automatically copies your notes from the original to the
 535        rewritten commit.  Defaults to `true`, but see
 536        "notes.rewriteRef" below.
 537
 538notes.rewriteMode::
 539        When copying notes during a rewrite (see the
 540        "notes.rewrite.<command>" option), determines what to do if
 541        the target commit already has a note.  Must be one of
 542        `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
 543        Defaults to `concatenate`.
 544+
 545This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
 546environment variable.
 547
 548notes.rewriteRef::
 549        When copying notes during a rewrite, specifies the (fully
 550        qualified) ref whose notes should be copied.  The ref may be a
 551        glob, in which case notes in all matching refs will be copied.
 552        You may also specify this configuration several times.
 553+
 554Does not have a default value; you must configure this variable to
 555enable note rewriting.  Set it to `refs/notes/commits` to enable
 556rewriting for the default commit notes.
 557+
 558This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
 559environment variable, which must be a colon separated list of refs or
 560globs.
 561
 562pack.window::
 563        The size of the window used by linkgit:git-pack-objects[1] when no
 564        window size is given on the command line. Defaults to 10.
 565
 566pack.depth::
 567        The maximum delta depth used by linkgit:git-pack-objects[1] when no
 568        maximum depth is given on the command line. Defaults to 50.
 569        Maximum value is 4095.
 570
 571pack.windowMemory::
 572        The maximum size of memory that is consumed by each thread
 573        in linkgit:git-pack-objects[1] for pack window memory when
 574        no limit is given on the command line.  The value can be
 575        suffixed with "k", "m", or "g".  When left unconfigured (or
 576        set explicitly to 0), there will be no limit.
 577
 578pack.compression::
 579        An integer -1..9, indicating the compression level for objects
 580        in a pack file. -1 is the zlib default. 0 means no
 581        compression, and 1..9 are various speed/size tradeoffs, 9 being
 582        slowest.  If not set,  defaults to core.compression.  If that is
 583        not set,  defaults to -1, the zlib default, which is "a default
 584        compromise between speed and compression (currently equivalent
 585        to level 6)."
 586+
 587Note that changing the compression level will not automatically recompress
 588all existing objects. You can force recompression by passing the -F option
 589to linkgit:git-repack[1].
 590
 591pack.island::
 592        An extended regular expression configuring a set of delta
 593        islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
 594        for details.
 595
 596pack.islandCore::
 597        Specify an island name which gets to have its objects be
 598        packed first. This creates a kind of pseudo-pack at the front
 599        of one pack, so that the objects from the specified island are
 600        hopefully faster to copy into any pack that should be served
 601        to a user requesting these objects. In practice this means
 602        that the island specified should likely correspond to what is
 603        the most commonly cloned in the repo. See also "DELTA ISLANDS"
 604        in linkgit:git-pack-objects[1].
 605
 606pack.deltaCacheSize::
 607        The maximum memory in bytes used for caching deltas in
 608        linkgit:git-pack-objects[1] before writing them out to a pack.
 609        This cache is used to speed up the writing object phase by not
 610        having to recompute the final delta result once the best match
 611        for all objects is found.  Repacking large repositories on machines
 612        which are tight with memory might be badly impacted by this though,
 613        especially if this cache pushes the system into swapping.
 614        A value of 0 means no limit. The smallest size of 1 byte may be
 615        used to virtually disable this cache. Defaults to 256 MiB.
 616
 617pack.deltaCacheLimit::
 618        The maximum size of a delta, that is cached in
 619        linkgit:git-pack-objects[1]. This cache is used to speed up the
 620        writing object phase by not having to recompute the final delta
 621        result once the best match for all objects is found.
 622        Defaults to 1000. Maximum value is 65535.
 623
 624pack.threads::
 625        Specifies the number of threads to spawn when searching for best
 626        delta matches.  This requires that linkgit:git-pack-objects[1]
 627        be compiled with pthreads otherwise this option is ignored with a
 628        warning. This is meant to reduce packing time on multiprocessor
 629        machines. The required amount of memory for the delta search window
 630        is however multiplied by the number of threads.
 631        Specifying 0 will cause Git to auto-detect the number of CPU's
 632        and set the number of threads accordingly.
 633
 634pack.indexVersion::
 635        Specify the default pack index version.  Valid values are 1 for
 636        legacy pack index used by Git versions prior to 1.5.2, and 2 for
 637        the new pack index with capabilities for packs larger than 4 GB
 638        as well as proper protection against the repacking of corrupted
 639        packs.  Version 2 is the default.  Note that version 2 is enforced
 640        and this config option ignored whenever the corresponding pack is
 641        larger than 2 GB.
 642+
 643If you have an old Git that does not understand the version 2 `*.idx` file,
 644cloning or fetching over a non native protocol (e.g. "http")
 645that will copy both `*.pack` file and corresponding `*.idx` file from the
 646other side may give you a repository that cannot be accessed with your
 647older version of Git. If the `*.pack` file is smaller than 2 GB, however,
 648you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
 649the `*.idx` file.
 650
 651pack.packSizeLimit::
 652        The maximum size of a pack.  This setting only affects
 653        packing to a file when repacking, i.e. the git:// protocol
 654        is unaffected.  It can be overridden by the `--max-pack-size`
 655        option of linkgit:git-repack[1].  Reaching this limit results
 656        in the creation of multiple packfiles; which in turn prevents
 657        bitmaps from being created.
 658        The minimum size allowed is limited to 1 MiB.
 659        The default is unlimited.
 660        Common unit suffixes of 'k', 'm', or 'g' are
 661        supported.
 662
 663pack.useBitmaps::
 664        When true, git will use pack bitmaps (if available) when packing
 665        to stdout (e.g., during the server side of a fetch). Defaults to
 666        true. You should not generally need to turn this off unless
 667        you are debugging pack bitmaps.
 668
 669pack.writeBitmaps (deprecated)::
 670        This is a deprecated synonym for `repack.writeBitmaps`.
 671
 672pack.writeBitmapHashCache::
 673        When true, git will include a "hash cache" section in the bitmap
 674        index (if one is written). This cache can be used to feed git's
 675        delta heuristics, potentially leading to better deltas between
 676        bitmapped and non-bitmapped objects (e.g., when serving a fetch
 677        between an older, bitmapped pack and objects that have been
 678        pushed since the last gc). The downside is that it consumes 4
 679        bytes per object of disk space, and that JGit's bitmap
 680        implementation does not understand it, causing it to complain if
 681        Git and JGit are used on the same repository. Defaults to false.
 682
 683pager.<cmd>::
 684        If the value is boolean, turns on or off pagination of the
 685        output of a particular Git subcommand when writing to a tty.
 686        Otherwise, turns on pagination for the subcommand using the
 687        pager specified by the value of `pager.<cmd>`.  If `--paginate`
 688        or `--no-pager` is specified on the command line, it takes
 689        precedence over this option.  To disable pagination for all
 690        commands, set `core.pager` or `GIT_PAGER` to `cat`.
 691
 692pretty.<name>::
 693        Alias for a --pretty= format string, as specified in
 694        linkgit:git-log[1]. Any aliases defined here can be used just
 695        as the built-in pretty formats could. For example,
 696        running `git config pretty.changelog "format:* %H %s"`
 697        would cause the invocation `git log --pretty=changelog`
 698        to be equivalent to running `git log "--pretty=format:* %H %s"`.
 699        Note that an alias with the same name as a built-in format
 700        will be silently ignored.
 701
 702protocol.allow::
 703        If set, provide a user defined default policy for all protocols which
 704        don't explicitly have a policy (`protocol.<name>.allow`).  By default,
 705        if unset, known-safe protocols (http, https, git, ssh, file) have a
 706        default policy of `always`, known-dangerous protocols (ext) have a
 707        default policy of `never`, and all other protocols have a default
 708        policy of `user`.  Supported policies:
 709+
 710--
 711
 712* `always` - protocol is always able to be used.
 713
 714* `never` - protocol is never able to be used.
 715
 716* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
 717  either unset or has a value of 1.  This policy should be used when you want a
 718  protocol to be directly usable by the user but don't want it used by commands which
 719  execute clone/fetch/push commands without user input, e.g. recursive
 720  submodule initialization.
 721
 722--
 723
 724protocol.<name>.allow::
 725        Set a policy to be used by protocol `<name>` with clone/fetch/push
 726        commands. See `protocol.allow` above for the available policies.
 727+
 728The protocol names currently used by git are:
 729+
 730--
 731  - `file`: any local file-based path (including `file://` URLs,
 732    or local paths)
 733
 734  - `git`: the anonymous git protocol over a direct TCP
 735    connection (or proxy, if configured)
 736
 737  - `ssh`: git over ssh (including `host:path` syntax,
 738    `ssh://`, etc).
 739
 740  - `http`: git over http, both "smart http" and "dumb http".
 741    Note that this does _not_ include `https`; if you want to configure
 742    both, you must do so individually.
 743
 744  - any external helpers are named by their protocol (e.g., use
 745    `hg` to allow the `git-remote-hg` helper)
 746--
 747
 748protocol.version::
 749        Experimental. If set, clients will attempt to communicate with a
 750        server using the specified protocol version.  If unset, no
 751        attempt will be made by the client to communicate using a
 752        particular protocol version, this results in protocol version 0
 753        being used.
 754        Supported versions:
 755+
 756--
 757
 758* `0` - the original wire protocol.
 759
 760* `1` - the original wire protocol with the addition of a version string
 761  in the initial response from the server.
 762
 763* `2` - link:technical/protocol-v2.html[wire protocol version 2].
 764
 765--
 766
 767include::pull-config.txt[]
 768
 769include::push-config.txt[]
 770
 771include::rebase-config.txt[]
 772
 773include::receive-config.txt[]
 774
 775remote.pushDefault::
 776        The remote to push to by default.  Overrides
 777        `branch.<name>.remote` for all branches, and is overridden by
 778        `branch.<name>.pushRemote` for specific branches.
 779
 780remote.<name>.url::
 781        The URL of a remote repository.  See linkgit:git-fetch[1] or
 782        linkgit:git-push[1].
 783
 784remote.<name>.pushurl::
 785        The push URL of a remote repository.  See linkgit:git-push[1].
 786
 787remote.<name>.proxy::
 788        For remotes that require curl (http, https and ftp), the URL to
 789        the proxy to use for that remote.  Set to the empty string to
 790        disable proxying for that remote.
 791
 792remote.<name>.proxyAuthMethod::
 793        For remotes that require curl (http, https and ftp), the method to use for
 794        authenticating against the proxy in use (probably set in
 795        `remote.<name>.proxy`). See `http.proxyAuthMethod`.
 796
 797remote.<name>.fetch::
 798        The default set of "refspec" for linkgit:git-fetch[1]. See
 799        linkgit:git-fetch[1].
 800
 801remote.<name>.push::
 802        The default set of "refspec" for linkgit:git-push[1]. See
 803        linkgit:git-push[1].
 804
 805remote.<name>.mirror::
 806        If true, pushing to this remote will automatically behave
 807        as if the `--mirror` option was given on the command line.
 808
 809remote.<name>.skipDefaultUpdate::
 810        If true, this remote will be skipped by default when updating
 811        using linkgit:git-fetch[1] or the `update` subcommand of
 812        linkgit:git-remote[1].
 813
 814remote.<name>.skipFetchAll::
 815        If true, this remote will be skipped by default when updating
 816        using linkgit:git-fetch[1] or the `update` subcommand of
 817        linkgit:git-remote[1].
 818
 819remote.<name>.receivepack::
 820        The default program to execute on the remote side when pushing.  See
 821        option --receive-pack of linkgit:git-push[1].
 822
 823remote.<name>.uploadpack::
 824        The default program to execute on the remote side when fetching.  See
 825        option --upload-pack of linkgit:git-fetch-pack[1].
 826
 827remote.<name>.tagOpt::
 828        Setting this value to --no-tags disables automatic tag following when
 829        fetching from remote <name>. Setting it to --tags will fetch every
 830        tag from remote <name>, even if they are not reachable from remote
 831        branch heads. Passing these flags directly to linkgit:git-fetch[1] can
 832        override this setting. See options --tags and --no-tags of
 833        linkgit:git-fetch[1].
 834
 835remote.<name>.vcs::
 836        Setting this to a value <vcs> will cause Git to interact with
 837        the remote with the git-remote-<vcs> helper.
 838
 839remote.<name>.prune::
 840        When set to true, fetching from this remote by default will also
 841        remove any remote-tracking references that no longer exist on the
 842        remote (as if the `--prune` option was given on the command line).
 843        Overrides `fetch.prune` settings, if any.
 844
 845remote.<name>.pruneTags::
 846        When set to true, fetching from this remote by default will also
 847        remove any local tags that no longer exist on the remote if pruning
 848        is activated in general via `remote.<name>.prune`, `fetch.prune` or
 849        `--prune`. Overrides `fetch.pruneTags` settings, if any.
 850+
 851See also `remote.<name>.prune` and the PRUNING section of
 852linkgit:git-fetch[1].
 853
 854remotes.<group>::
 855        The list of remotes which are fetched by "git remote update
 856        <group>".  See linkgit:git-remote[1].
 857
 858repack.useDeltaBaseOffset::
 859        By default, linkgit:git-repack[1] creates packs that use
 860        delta-base offset. If you need to share your repository with
 861        Git older than version 1.4.4, either directly or via a dumb
 862        protocol such as http, then you need to set this option to
 863        "false" and repack. Access from old Git versions over the
 864        native protocol are unaffected by this option.
 865
 866repack.packKeptObjects::
 867        If set to true, makes `git repack` act as if
 868        `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
 869        details. Defaults to `false` normally, but `true` if a bitmap
 870        index is being written (either via `--write-bitmap-index` or
 871        `repack.writeBitmaps`).
 872
 873repack.useDeltaIslands::
 874        If set to true, makes `git repack` act as if `--delta-islands`
 875        was passed. Defaults to `false`.
 876
 877repack.writeBitmaps::
 878        When true, git will write a bitmap index when packing all
 879        objects to disk (e.g., when `git repack -a` is run).  This
 880        index can speed up the "counting objects" phase of subsequent
 881        packs created for clones and fetches, at the cost of some disk
 882        space and extra time spent on the initial repack.  This has
 883        no effect if multiple packfiles are created.
 884        Defaults to false.
 885
 886rerere.autoUpdate::
 887        When set to true, `git-rerere` updates the index with the
 888        resulting contents after it cleanly resolves conflicts using
 889        previously recorded resolution.  Defaults to false.
 890
 891rerere.enabled::
 892        Activate recording of resolved conflicts, so that identical
 893        conflict hunks can be resolved automatically, should they be
 894        encountered again.  By default, linkgit:git-rerere[1] is
 895        enabled if there is an `rr-cache` directory under the
 896        `$GIT_DIR`, e.g. if "rerere" was previously used in the
 897        repository.
 898
 899reset.quiet::
 900        When set to true, 'git reset' will default to the '--quiet' option.
 901
 902include::sendemail-config.txt[]
 903
 904sequence.editor::
 905        Text editor used by `git rebase -i` for editing the rebase instruction file.
 906        The value is meant to be interpreted by the shell when it is used.
 907        It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
 908        When not configured the default commit message editor is used instead.
 909
 910showBranch.default::
 911        The default set of branches for linkgit:git-show-branch[1].
 912        See linkgit:git-show-branch[1].
 913
 914splitIndex.maxPercentChange::
 915        When the split index feature is used, this specifies the
 916        percent of entries the split index can contain compared to the
 917        total number of entries in both the split index and the shared
 918        index before a new shared index is written.
 919        The value should be between 0 and 100. If the value is 0 then
 920        a new shared index is always written, if it is 100 a new
 921        shared index is never written.
 922        By default the value is 20, so a new shared index is written
 923        if the number of entries in the split index would be greater
 924        than 20 percent of the total number of entries.
 925        See linkgit:git-update-index[1].
 926
 927splitIndex.sharedIndexExpire::
 928        When the split index feature is used, shared index files that
 929        were not modified since the time this variable specifies will
 930        be removed when a new shared index file is created. The value
 931        "now" expires all entries immediately, and "never" suppresses
 932        expiration altogether.
 933        The default value is "2.weeks.ago".
 934        Note that a shared index file is considered modified (for the
 935        purpose of expiration) each time a new split-index file is
 936        either created based on it or read from it.
 937        See linkgit:git-update-index[1].
 938
 939include::config/ssh.txt[]
 940
 941status.relativePaths::
 942        By default, linkgit:git-status[1] shows paths relative to the
 943        current directory. Setting this variable to `false` shows paths
 944        relative to the repository root (this was the default for Git
 945        prior to v1.5.4).
 946
 947status.short::
 948        Set to true to enable --short by default in linkgit:git-status[1].
 949        The option --no-short takes precedence over this variable.
 950
 951status.branch::
 952        Set to true to enable --branch by default in linkgit:git-status[1].
 953        The option --no-branch takes precedence over this variable.
 954
 955status.displayCommentPrefix::
 956        If set to true, linkgit:git-status[1] will insert a comment
 957        prefix before each output line (starting with
 958        `core.commentChar`, i.e. `#` by default). This was the
 959        behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
 960        Defaults to false.
 961
 962status.renameLimit::
 963        The number of files to consider when performing rename detection
 964        in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
 965        the value of diff.renameLimit.
 966
 967status.renames::
 968        Whether and how Git detects renames in linkgit:git-status[1] and
 969        linkgit:git-commit[1] .  If set to "false", rename detection is
 970        disabled. If set to "true", basic rename detection is enabled.
 971        If set to "copies" or "copy", Git will detect copies, as well.
 972        Defaults to the value of diff.renames.
 973
 974status.showStash::
 975        If set to true, linkgit:git-status[1] will display the number of
 976        entries currently stashed away.
 977        Defaults to false.
 978
 979status.showUntrackedFiles::
 980        By default, linkgit:git-status[1] and linkgit:git-commit[1] show
 981        files which are not currently tracked by Git. Directories which
 982        contain only untracked files, are shown with the directory name
 983        only. Showing untracked files means that Git needs to lstat() all
 984        the files in the whole repository, which might be slow on some
 985        systems. So, this variable controls how the commands displays
 986        the untracked files. Possible values are:
 987+
 988--
 989* `no` - Show no untracked files.
 990* `normal` - Show untracked files and directories.
 991* `all` - Show also individual files in untracked directories.
 992--
 993+
 994If this variable is not specified, it defaults to 'normal'.
 995This variable can be overridden with the -u|--untracked-files option
 996of linkgit:git-status[1] and linkgit:git-commit[1].
 997
 998status.submoduleSummary::
 999        Defaults to false.
1000        If this is set to a non zero number or true (identical to -1 or an
1001        unlimited number), the submodule summary will be enabled and a
1002        summary of commits for modified submodules will be shown (see
1003        --summary-limit option of linkgit:git-submodule[1]). Please note
1004        that the summary output command will be suppressed for all
1005        submodules when `diff.ignoreSubmodules` is set to 'all' or only
1006        for those submodules where `submodule.<name>.ignore=all`. The only
1007        exception to that rule is that status and commit will show staged
1008        submodule changes. To
1009        also view the summary for ignored submodules you can either use
1010        the --ignore-submodules=dirty command-line option or the 'git
1011        submodule summary' command, which shows a similar output but does
1012        not honor these settings.
1013
1014stash.showPatch::
1015        If this is set to true, the `git stash show` command without an
1016        option will show the stash entry in patch form.  Defaults to false.
1017        See description of 'show' command in linkgit:git-stash[1].
1018
1019stash.showStat::
1020        If this is set to true, the `git stash show` command without an
1021        option will show diffstat of the stash entry.  Defaults to true.
1022        See description of 'show' command in linkgit:git-stash[1].
1023
1024include::submodule-config.txt[]
1025
1026tag.forceSignAnnotated::
1027        A boolean to specify whether annotated tags created should be GPG signed.
1028        If `--annotate` is specified on the command line, it takes
1029        precedence over this option.
1030
1031tag.sort::
1032        This variable controls the sort ordering of tags when displayed by
1033        linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
1034        value of this variable will be used as the default.
1035
1036tar.umask::
1037        This variable can be used to restrict the permission bits of
1038        tar archive entries.  The default is 0002, which turns off the
1039        world write bit.  The special value "user" indicates that the
1040        archiving user's umask will be used instead.  See umask(2) and
1041        linkgit:git-archive[1].
1042
1043transfer.fsckObjects::
1044        When `fetch.fsckObjects` or `receive.fsckObjects` are
1045        not set, the value of this variable is used instead.
1046        Defaults to false.
1047+
1048When set, the fetch or receive will abort in the case of a malformed
1049object or a link to a nonexistent object. In addition, various other
1050issues are checked for, including legacy issues (see `fsck.<msg-id>`),
1051and potential security issues like the existence of a `.GIT` directory
1052or a malicious `.gitmodules` file (see the release notes for v2.2.1
1053and v2.17.1 for details). Other sanity and security checks may be
1054added in future releases.
1055+
1056On the receiving side, failing fsckObjects will make those objects
1057unreachable, see "QUARANTINE ENVIRONMENT" in
1058linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
1059instead be left unreferenced in the repository.
1060+
1061Due to the non-quarantine nature of the `fetch.fsckObjects`
1062implementation it can not be relied upon to leave the object store
1063clean like `receive.fsckObjects` can.
1064+
1065As objects are unpacked they're written to the object store, so there
1066can be cases where malicious objects get introduced even though the
1067"fetch" failed, only to have a subsequent "fetch" succeed because only
1068new incoming objects are checked, not those that have already been
1069written to the object store. That difference in behavior should not be
1070relied upon. In the future, such objects may be quarantined for
1071"fetch" as well.
1072+
1073For now, the paranoid need to find some way to emulate the quarantine
1074environment if they'd like the same protection as "push". E.g. in the
1075case of an internal mirror do the mirroring in two steps, one to fetch
1076the untrusted objects, and then do a second "push" (which will use the
1077quarantine) to another internal repo, and have internal clients
1078consume this pushed-to repository, or embargo internal fetches and
1079only allow them once a full "fsck" has run (and no new fetches have
1080happened in the meantime).
1081
1082transfer.hideRefs::
1083        String(s) `receive-pack` and `upload-pack` use to decide which
1084        refs to omit from their initial advertisements.  Use more than
1085        one definition to specify multiple prefix strings. A ref that is
1086        under the hierarchies listed in the value of this variable is
1087        excluded, and is hidden when responding to `git push` or `git
1088        fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
1089        program-specific versions of this config.
1090+
1091You may also include a `!` in front of the ref name to negate the entry,
1092explicitly exposing it, even if an earlier entry marked it as hidden.
1093If you have multiple hideRefs values, later entries override earlier ones
1094(and entries in more-specific config files override less-specific ones).
1095+
1096If a namespace is in use, the namespace prefix is stripped from each
1097reference before it is matched against `transfer.hiderefs` patterns.
1098For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
1099the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
1100is omitted from the advertisements but `refs/heads/master` and
1101`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
1102"have" lines. In order to match refs before stripping, add a `^` in front of
1103the ref name. If you combine `!` and `^`, `!` must be specified first.
1104+
1105Even if you hide refs, a client may still be able to steal the target
1106objects via the techniques described in the "SECURITY" section of the
1107linkgit:gitnamespaces[7] man page; it's best to keep private data in a
1108separate repository.
1109
1110transfer.unpackLimit::
1111        When `fetch.unpackLimit` or `receive.unpackLimit` are
1112        not set, the value of this variable is used instead.
1113        The default value is 100.
1114
1115uploadarchive.allowUnreachable::
1116        If true, allow clients to use `git archive --remote` to request
1117        any tree, whether reachable from the ref tips or not. See the
1118        discussion in the "SECURITY" section of
1119        linkgit:git-upload-archive[1] for more details. Defaults to
1120        `false`.
1121
1122uploadpack.hideRefs::
1123        This variable is the same as `transfer.hideRefs`, but applies
1124        only to `upload-pack` (and so affects only fetches, not pushes).
1125        An attempt to fetch a hidden ref by `git fetch` will fail.  See
1126        also `uploadpack.allowTipSHA1InWant`.
1127
1128uploadpack.allowTipSHA1InWant::
1129        When `uploadpack.hideRefs` is in effect, allow `upload-pack`
1130        to accept a fetch request that asks for an object at the tip
1131        of a hidden ref (by default, such a request is rejected).
1132        See also `uploadpack.hideRefs`.  Even if this is false, a client
1133        may be able to steal objects via the techniques described in the
1134        "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
1135        best to keep private data in a separate repository.
1136
1137uploadpack.allowReachableSHA1InWant::
1138        Allow `upload-pack` to accept a fetch request that asks for an
1139        object that is reachable from any ref tip. However, note that
1140        calculating object reachability is computationally expensive.
1141        Defaults to `false`.  Even if this is false, a client may be able
1142        to steal objects via the techniques described in the "SECURITY"
1143        section of the linkgit:gitnamespaces[7] man page; it's best to
1144        keep private data in a separate repository.
1145
1146uploadpack.allowAnySHA1InWant::
1147        Allow `upload-pack` to accept a fetch request that asks for any
1148        object at all.
1149        Defaults to `false`.
1150
1151uploadpack.keepAlive::
1152        When `upload-pack` has started `pack-objects`, there may be a
1153        quiet period while `pack-objects` prepares the pack. Normally
1154        it would output progress information, but if `--quiet` was used
1155        for the fetch, `pack-objects` will output nothing at all until
1156        the pack data begins. Some clients and networks may consider
1157        the server to be hung and give up. Setting this option instructs
1158        `upload-pack` to send an empty keepalive packet every
1159        `uploadpack.keepAlive` seconds. Setting this option to 0
1160        disables keepalive packets entirely. The default is 5 seconds.
1161
1162uploadpack.packObjectsHook::
1163        If this option is set, when `upload-pack` would run
1164        `git pack-objects` to create a packfile for a client, it will
1165        run this shell command instead.  The `pack-objects` command and
1166        arguments it _would_ have run (including the `git pack-objects`
1167        at the beginning) are appended to the shell command. The stdin
1168        and stdout of the hook are treated as if `pack-objects` itself
1169        was run. I.e., `upload-pack` will feed input intended for
1170        `pack-objects` to the hook, and expects a completed packfile on
1171        stdout.
1172+
1173Note that this configuration variable is ignored if it is seen in the
1174repository-level config (this is a safety measure against fetching from
1175untrusted repositories).
1176
1177uploadpack.allowFilter::
1178        If this option is set, `upload-pack` will support partial
1179        clone and partial fetch object filtering.
1180
1181uploadpack.allowRefInWant::
1182        If this option is set, `upload-pack` will support the `ref-in-want`
1183        feature of the protocol version 2 `fetch` command.  This feature
1184        is intended for the benefit of load-balanced servers which may
1185        not have the same view of what OIDs their refs point to due to
1186        replication delay.
1187
1188url.<base>.insteadOf::
1189        Any URL that starts with this value will be rewritten to
1190        start, instead, with <base>. In cases where some site serves a
1191        large number of repositories, and serves them with multiple
1192        access methods, and some users need to use different access
1193        methods, this feature allows people to specify any of the
1194        equivalent URLs and have Git automatically rewrite the URL to
1195        the best alternative for the particular user, even for a
1196        never-before-seen repository on the site.  When more than one
1197        insteadOf strings match a given URL, the longest match is used.
1198+
1199Note that any protocol restrictions will be applied to the rewritten
1200URL. If the rewrite changes the URL to use a custom protocol or remote
1201helper, you may need to adjust the `protocol.*.allow` config to permit
1202the request.  In particular, protocols you expect to use for submodules
1203must be set to `always` rather than the default of `user`. See the
1204description of `protocol.allow` above.
1205
1206url.<base>.pushInsteadOf::
1207        Any URL that starts with this value will not be pushed to;
1208        instead, it will be rewritten to start with <base>, and the
1209        resulting URL will be pushed to. In cases where some site serves
1210        a large number of repositories, and serves them with multiple
1211        access methods, some of which do not allow push, this feature
1212        allows people to specify a pull-only URL and have Git
1213        automatically use an appropriate URL to push, even for a
1214        never-before-seen repository on the site.  When more than one
1215        pushInsteadOf strings match a given URL, the longest match is
1216        used.  If a remote has an explicit pushurl, Git will ignore this
1217        setting for that remote.
1218
1219user.email::
1220        Your email address to be recorded in any newly created commits.
1221        Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
1222        `EMAIL` environment variables.  See linkgit:git-commit-tree[1].
1223
1224user.name::
1225        Your full name to be recorded in any newly created commits.
1226        Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
1227        environment variables.  See linkgit:git-commit-tree[1].
1228
1229user.useConfigOnly::
1230        Instruct Git to avoid trying to guess defaults for `user.email`
1231        and `user.name`, and instead retrieve the values only from the
1232        configuration. For example, if you have multiple email addresses
1233        and would like to use a different one for each repository, then
1234        with this configuration option set to `true` in the global config
1235        along with a name, Git will prompt you to set up an email before
1236        making new commits in a newly cloned repository.
1237        Defaults to `false`.
1238
1239user.signingKey::
1240        If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
1241        key you want it to automatically when creating a signed tag or
1242        commit, you can override the default selection with this variable.
1243        This option is passed unchanged to gpg's --local-user parameter,
1244        so you may specify a key using any method that gpg supports.
1245
1246versionsort.prereleaseSuffix (deprecated)::
1247        Deprecated alias for `versionsort.suffix`.  Ignored if
1248        `versionsort.suffix` is set.
1249
1250versionsort.suffix::
1251        Even when version sort is used in linkgit:git-tag[1], tagnames
1252        with the same base version but different suffixes are still sorted
1253        lexicographically, resulting e.g. in prerelease tags appearing
1254        after the main release (e.g. "1.0-rc1" after "1.0").  This
1255        variable can be specified to determine the sorting order of tags
1256        with different suffixes.
1257+
1258By specifying a single suffix in this variable, any tagname containing
1259that suffix will appear before the corresponding main release.  E.g. if
1260the variable is set to "-rc", then all "1.0-rcX" tags will appear before
1261"1.0".  If specified multiple times, once per suffix, then the order of
1262suffixes in the configuration will determine the sorting order of tagnames
1263with those suffixes.  E.g. if "-pre" appears before "-rc" in the
1264configuration, then all "1.0-preX" tags will be listed before any
1265"1.0-rcX" tags.  The placement of the main release tag relative to tags
1266with various suffixes can be determined by specifying the empty suffix
1267among those other suffixes.  E.g. if the suffixes "-rc", "", "-ck" and
1268"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
1269are listed first, followed by "v4.8", then "v4.8-ckX" and finally
1270"v4.8-bfsX".
1271+
1272If more than one suffixes match the same tagname, then that tagname will
1273be sorted according to the suffix which starts at the earliest position in
1274the tagname.  If more than one different matching suffixes start at
1275that earliest position, then that tagname will be sorted according to the
1276longest of those suffixes.
1277The sorting order between different suffixes is undefined if they are
1278in multiple config files.
1279
1280web.browser::
1281        Specify a web browser that may be used by some commands.
1282        Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
1283        may use it.
1284
1285worktree.guessRemote::
1286        With `add`, if no branch argument, and neither of `-b` nor
1287        `-B` nor `--detach` are given, the command defaults to
1288        creating a new branch from HEAD.  If `worktree.guessRemote` is
1289        set to true, `worktree add` tries to find a remote-tracking
1290        branch whose name uniquely matches the new branch name.  If
1291        such a branch exists, it is checked out and set as "upstream"
1292        for the new branch.  If no such match can be found, it falls
1293        back to creating a new branch from the current HEAD.