f207cae90cf97b76b94b0f0deb12993d9262da99
   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
 298am.keepcr::
 299        If true, git-am will call git-mailsplit for patches in mbox format
 300        with parameter `--keep-cr`. In this case git-mailsplit will
 301        not remove `\r` from lines ending with `\r\n`. Can be overridden
 302        by giving `--no-keep-cr` from the command line.
 303        See linkgit:git-am[1], linkgit:git-mailsplit[1].
 304
 305am.threeWay::
 306        By default, `git am` will fail if the patch does not apply cleanly. When
 307        set to true, this setting tells `git am` to fall back on 3-way merge if
 308        the patch records the identity of blobs it is supposed to apply to and
 309        we have those blobs available locally (equivalent to giving the `--3way`
 310        option from the command line). Defaults to `false`.
 311        See linkgit:git-am[1].
 312
 313apply.ignoreWhitespace::
 314        When set to 'change', tells 'git apply' to ignore changes in
 315        whitespace, in the same way as the `--ignore-space-change`
 316        option.
 317        When set to one of: no, none, never, false tells 'git apply' to
 318        respect all whitespace differences.
 319        See linkgit:git-apply[1].
 320
 321apply.whitespace::
 322        Tells 'git apply' how to handle whitespaces, in the same way
 323        as the `--whitespace` option. See linkgit:git-apply[1].
 324
 325blame.blankBoundary::
 326        Show blank commit object name for boundary commits in
 327        linkgit:git-blame[1]. This option defaults to false.
 328
 329blame.coloring::
 330        This determines the coloring scheme to be applied to blame
 331        output. It can be 'repeatedLines', 'highlightRecent',
 332        or 'none' which is the default.
 333
 334blame.date::
 335        Specifies the format used to output dates in linkgit:git-blame[1].
 336        If unset the iso format is used. For supported values,
 337        see the discussion of the `--date` option at linkgit:git-log[1].
 338
 339blame.showEmail::
 340        Show the author email instead of author name in linkgit:git-blame[1].
 341        This option defaults to false.
 342
 343blame.showRoot::
 344        Do not treat root commits as boundaries in linkgit:git-blame[1].
 345        This option defaults to false.
 346
 347branch.autoSetupMerge::
 348        Tells 'git branch' and 'git checkout' to set up new branches
 349        so that linkgit:git-pull[1] will appropriately merge from the
 350        starting point branch. Note that even if this option is not set,
 351        this behavior can be chosen per-branch using the `--track`
 352        and `--no-track` options. The valid settings are: `false` -- no
 353        automatic setup is done; `true` -- automatic setup is done when the
 354        starting point is a remote-tracking branch; `always` --
 355        automatic setup is done when the starting point is either a
 356        local branch or remote-tracking
 357        branch. This option defaults to true.
 358
 359branch.autoSetupRebase::
 360        When a new branch is created with 'git branch' or 'git checkout'
 361        that tracks another branch, this variable tells Git to set
 362        up pull to rebase instead of merge (see "branch.<name>.rebase").
 363        When `never`, rebase is never automatically set to true.
 364        When `local`, rebase is set to true for tracked branches of
 365        other local branches.
 366        When `remote`, rebase is set to true for tracked branches of
 367        remote-tracking branches.
 368        When `always`, rebase will be set to true for all tracking
 369        branches.
 370        See "branch.autoSetupMerge" for details on how to set up a
 371        branch to track another branch.
 372        This option defaults to never.
 373
 374branch.sort::
 375        This variable controls the sort ordering of branches when displayed by
 376        linkgit:git-branch[1]. Without the "--sort=<value>" option provided, the
 377        value of this variable will be used as the default.
 378        See linkgit:git-for-each-ref[1] field names for valid values.
 379
 380branch.<name>.remote::
 381        When on branch <name>, it tells 'git fetch' and 'git push'
 382        which remote to fetch from/push to.  The remote to push to
 383        may be overridden with `remote.pushDefault` (for all branches).
 384        The remote to push to, for the current branch, may be further
 385        overridden by `branch.<name>.pushRemote`.  If no remote is
 386        configured, or if you are not on any branch, it defaults to
 387        `origin` for fetching and `remote.pushDefault` for pushing.
 388        Additionally, `.` (a period) is the current local repository
 389        (a dot-repository), see `branch.<name>.merge`'s final note below.
 390
 391branch.<name>.pushRemote::
 392        When on branch <name>, it overrides `branch.<name>.remote` for
 393        pushing.  It also overrides `remote.pushDefault` for pushing
 394        from branch <name>.  When you pull from one place (e.g. your
 395        upstream) and push to another place (e.g. your own publishing
 396        repository), you would want to set `remote.pushDefault` to
 397        specify the remote to push to for all branches, and use this
 398        option to override it for a specific branch.
 399
 400branch.<name>.merge::
 401        Defines, together with branch.<name>.remote, the upstream branch
 402        for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
 403        branch to merge and can also affect 'git push' (see push.default).
 404        When in branch <name>, it tells 'git fetch' the default
 405        refspec to be marked for merging in FETCH_HEAD. The value is
 406        handled like the remote part of a refspec, and must match a
 407        ref which is fetched from the remote given by
 408        "branch.<name>.remote".
 409        The merge information is used by 'git pull' (which at first calls
 410        'git fetch') to lookup the default branch for merging. Without
 411        this option, 'git pull' defaults to merge the first refspec fetched.
 412        Specify multiple values to get an octopus merge.
 413        If you wish to setup 'git pull' so that it merges into <name> from
 414        another branch in the local repository, you can point
 415        branch.<name>.merge to the desired branch, and use the relative path
 416        setting `.` (a period) for branch.<name>.remote.
 417
 418branch.<name>.mergeOptions::
 419        Sets default options for merging into branch <name>. The syntax and
 420        supported options are the same as those of linkgit:git-merge[1], but
 421        option values containing whitespace characters are currently not
 422        supported.
 423
 424branch.<name>.rebase::
 425        When true, rebase the branch <name> on top of the fetched branch,
 426        instead of merging the default branch from the default remote when
 427        "git pull" is run. See "pull.rebase" for doing this in a non
 428        branch-specific manner.
 429+
 430When `merges`, pass the `--rebase-merges` option to 'git rebase'
 431so that the local merge commits are included in the rebase (see
 432linkgit:git-rebase[1] for details).
 433+
 434When preserve, also pass `--preserve-merges` along to 'git rebase'
 435so that locally committed merge commits will not be flattened
 436by running 'git pull'.
 437+
 438When the value is `interactive`, the rebase is run in interactive mode.
 439+
 440*NOTE*: this is a possibly dangerous operation; do *not* use
 441it unless you understand the implications (see linkgit:git-rebase[1]
 442for details).
 443
 444branch.<name>.description::
 445        Branch description, can be edited with
 446        `git branch --edit-description`. Branch description is
 447        automatically added in the format-patch cover letter or
 448        request-pull summary.
 449
 450browser.<tool>.cmd::
 451        Specify the command to invoke the specified browser. The
 452        specified command is evaluated in shell with the URLs passed
 453        as arguments. (See linkgit:git-web{litdd}browse[1].)
 454
 455browser.<tool>.path::
 456        Override the path for the given tool that may be used to
 457        browse HTML help (see `-w` option in linkgit:git-help[1]) or a
 458        working repository in gitweb (see linkgit:git-instaweb[1]).
 459
 460checkout.defaultRemote::
 461        When you run 'git checkout <something>' and only have one
 462        remote, it may implicitly fall back on checking out and
 463        tracking e.g. 'origin/<something>'. This stops working as soon
 464        as you have more than one remote with a '<something>'
 465        reference. This setting allows for setting the name of a
 466        preferred remote that should always win when it comes to
 467        disambiguation. The typical use-case is to set this to
 468        `origin`.
 469+
 470Currently this is used by linkgit:git-checkout[1] when 'git checkout
 471<something>' will checkout the '<something>' branch on another remote,
 472and by linkgit:git-worktree[1] when 'git worktree add' refers to a
 473remote branch. This setting might be used for other checkout-like
 474commands or functionality in the future.
 475
 476checkout.optimizeNewBranch::
 477        Optimizes the performance of "git checkout -b <new_branch>" when
 478        using sparse-checkout.  When set to true, git will not update the
 479        repo based on the current sparse-checkout settings.  This means it
 480        will not update the skip-worktree bit in the index nor add/remove
 481        files in the working directory to reflect the current sparse checkout
 482        settings nor will it show the local changes.
 483
 484clean.requireForce::
 485        A boolean to make git-clean do nothing unless given -f,
 486        -i or -n.   Defaults to true.
 487
 488color.advice::
 489        A boolean to enable/disable color in hints (e.g. when a push
 490        failed, see `advice.*` for a list).  May be set to `always`,
 491        `false` (or `never`) or `auto` (or `true`), in which case colors
 492        are used only when the error output goes to a terminal. If
 493        unset, then the value of `color.ui` is used (`auto` by default).
 494
 495color.advice.hint::
 496        Use customized color for hints.
 497
 498color.blame.highlightRecent::
 499        This can be used to color the metadata of a blame line depending
 500        on age of the line.
 501+
 502This setting should be set to a comma-separated list of color and date settings,
 503starting and ending with a color, the dates should be set from oldest to newest.
 504The metadata will be colored given the colors if the the line was introduced
 505before the given timestamp, overwriting older timestamped colors.
 506+
 507Instead of an absolute timestamp relative timestamps work as well, e.g.
 5082.weeks.ago is valid to address anything older than 2 weeks.
 509+
 510It defaults to 'blue,12 month ago,white,1 month ago,red', which colors
 511everything older than one year blue, recent changes between one month and
 512one year old are kept white, and lines introduced within the last month are
 513colored red.
 514
 515color.blame.repeatedLines::
 516        Use the customized color for the part of git-blame output that
 517        is repeated meta information per line (such as commit id,
 518        author name, date and timezone). Defaults to cyan.
 519
 520color.branch::
 521        A boolean to enable/disable color in the output of
 522        linkgit:git-branch[1]. May be set to `always`,
 523        `false` (or `never`) or `auto` (or `true`), in which case colors are used
 524        only when the output is to a terminal. If unset, then the
 525        value of `color.ui` is used (`auto` by default).
 526
 527color.branch.<slot>::
 528        Use customized color for branch coloration. `<slot>` is one of
 529        `current` (the current branch), `local` (a local branch),
 530        `remote` (a remote-tracking branch in refs/remotes/),
 531        `upstream` (upstream tracking branch), `plain` (other
 532        refs).
 533
 534color.diff::
 535        Whether to use ANSI escape sequences to add color to patches.
 536        If this is set to `always`, linkgit:git-diff[1],
 537        linkgit:git-log[1], and linkgit:git-show[1] will use color
 538        for all patches.  If it is set to `true` or `auto`, those
 539        commands will only use color when output is to the terminal.
 540        If unset, then the value of `color.ui` is used (`auto` by
 541        default).
 542+
 543This does not affect linkgit:git-format-patch[1] or the
 544'git-diff-{asterisk}' plumbing commands.  Can be overridden on the
 545command line with the `--color[=<when>]` option.
 546
 547color.diff.<slot>::
 548        Use customized color for diff colorization.  `<slot>` specifies
 549        which part of the patch to use the specified color, and is one
 550        of `context` (context text - `plain` is a historical synonym),
 551        `meta` (metainformation), `frag`
 552        (hunk header), 'func' (function in hunk header), `old` (removed lines),
 553        `new` (added lines), `commit` (commit headers), `whitespace`
 554        (highlighting whitespace errors), `oldMoved` (deleted lines),
 555        `newMoved` (added lines), `oldMovedDimmed`, `oldMovedAlternative`,
 556        `oldMovedAlternativeDimmed`, `newMovedDimmed`, `newMovedAlternative`
 557        `newMovedAlternativeDimmed` (See the '<mode>'
 558        setting of '--color-moved' in linkgit:git-diff[1] for details),
 559        `contextDimmed`, `oldDimmed`, `newDimmed`, `contextBold`,
 560        `oldBold`, and `newBold` (see linkgit:git-range-diff[1] for details).
 561
 562color.decorate.<slot>::
 563        Use customized color for 'git log --decorate' output.  `<slot>` is one
 564        of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local
 565        branches, remote-tracking branches, tags, stash and HEAD, respectively
 566        and `grafted` for grafted commits.
 567
 568color.grep::
 569        When set to `always`, always highlight matches.  When `false` (or
 570        `never`), never.  When set to `true` or `auto`, use color only
 571        when the output is written to the terminal.  If unset, then the
 572        value of `color.ui` is used (`auto` by default).
 573
 574color.grep.<slot>::
 575        Use customized color for grep colorization.  `<slot>` specifies which
 576        part of the line to use the specified color, and is one of
 577+
 578--
 579`context`;;
 580        non-matching text in context lines (when using `-A`, `-B`, or `-C`)
 581`filename`;;
 582        filename prefix (when not using `-h`)
 583`function`;;
 584        function name lines (when using `-p`)
 585`lineNumber`;;
 586        line number prefix (when using `-n`)
 587`column`;;
 588        column number prefix (when using `--column`)
 589`match`;;
 590        matching text (same as setting `matchContext` and `matchSelected`)
 591`matchContext`;;
 592        matching text in context lines
 593`matchSelected`;;
 594        matching text in selected lines
 595`selected`;;
 596        non-matching text in selected lines
 597`separator`;;
 598        separators between fields on a line (`:`, `-`, and `=`)
 599        and between hunks (`--`)
 600--
 601
 602color.interactive::
 603        When set to `always`, always use colors for interactive prompts
 604        and displays (such as those used by "git-add --interactive" and
 605        "git-clean --interactive"). When false (or `never`), never.
 606        When set to `true` or `auto`, use colors only when the output is
 607        to the terminal. If unset, then the value of `color.ui` is
 608        used (`auto` by default).
 609
 610color.interactive.<slot>::
 611        Use customized color for 'git add --interactive' and 'git clean
 612        --interactive' output. `<slot>` may be `prompt`, `header`, `help`
 613        or `error`, for four distinct types of normal output from
 614        interactive commands.
 615
 616color.pager::
 617        A boolean to enable/disable colored output when the pager is in
 618        use (default is true).
 619
 620color.push::
 621        A boolean to enable/disable color in push errors. May be set to
 622        `always`, `false` (or `never`) or `auto` (or `true`), in which
 623        case colors are used only when the error output goes to a terminal.
 624        If unset, then the value of `color.ui` is used (`auto` by default).
 625
 626color.push.error::
 627        Use customized color for push errors.
 628
 629color.remote::
 630        If set, keywords at the start of the line are highlighted. The
 631        keywords are "error", "warning", "hint" and "success", and are
 632        matched case-insensitively. May be set to `always`, `false` (or
 633        `never`) or `auto` (or `true`). If unset, then the value of
 634        `color.ui` is used (`auto` by default).
 635
 636color.remote.<slot>::
 637        Use customized color for each remote keyword. `<slot>` may be
 638        `hint`, `warning`, `success` or `error` which match the
 639        corresponding keyword.
 640
 641color.showBranch::
 642        A boolean to enable/disable color in the output of
 643        linkgit:git-show-branch[1]. May be set to `always`,
 644        `false` (or `never`) or `auto` (or `true`), in which case colors are used
 645        only when the output is to a terminal. If unset, then the
 646        value of `color.ui` is used (`auto` by default).
 647
 648color.status::
 649        A boolean to enable/disable color in the output of
 650        linkgit:git-status[1]. May be set to `always`,
 651        `false` (or `never`) or `auto` (or `true`), in which case colors are used
 652        only when the output is to a terminal. If unset, then the
 653        value of `color.ui` is used (`auto` by default).
 654
 655color.status.<slot>::
 656        Use customized color for status colorization. `<slot>` is
 657        one of `header` (the header text of the status message),
 658        `added` or `updated` (files which are added but not committed),
 659        `changed` (files which are changed but not added in the index),
 660        `untracked` (files which are not tracked by Git),
 661        `branch` (the current branch),
 662        `nobranch` (the color the 'no branch' warning is shown in, defaulting
 663        to red),
 664        `localBranch` or `remoteBranch` (the local and remote branch names,
 665        respectively, when branch and tracking information is displayed in the
 666        status short-format), or
 667        `unmerged` (files which have unmerged changes).
 668
 669color.transport::
 670        A boolean to enable/disable color when pushes are rejected. May be
 671        set to `always`, `false` (or `never`) or `auto` (or `true`), in which
 672        case colors are used only when the error output goes to a terminal.
 673        If unset, then the value of `color.ui` is used (`auto` by default).
 674
 675color.transport.rejected::
 676        Use customized color when a push was rejected.
 677
 678color.ui::
 679        This variable determines the default value for variables such
 680        as `color.diff` and `color.grep` that control the use of color
 681        per command family. Its scope will expand as more commands learn
 682        configuration to set a default for the `--color` option.  Set it
 683        to `false` or `never` if you prefer Git commands not to use
 684        color unless enabled explicitly with some other configuration
 685        or the `--color` option. Set it to `always` if you want all
 686        output not intended for machine consumption to use color, to
 687        `true` or `auto` (this is the default since Git 1.8.4) if you
 688        want such output to use color when written to the terminal.
 689
 690column.ui::
 691        Specify whether supported commands should output in columns.
 692        This variable consists of a list of tokens separated by spaces
 693        or commas:
 694+
 695These options control when the feature should be enabled
 696(defaults to 'never'):
 697+
 698--
 699`always`;;
 700        always show in columns
 701`never`;;
 702        never show in columns
 703`auto`;;
 704        show in columns if the output is to the terminal
 705--
 706+
 707These options control layout (defaults to 'column').  Setting any
 708of these implies 'always' if none of 'always', 'never', or 'auto' are
 709specified.
 710+
 711--
 712`column`;;
 713        fill columns before rows
 714`row`;;
 715        fill rows before columns
 716`plain`;;
 717        show in one column
 718--
 719+
 720Finally, these options can be combined with a layout option (defaults
 721to 'nodense'):
 722+
 723--
 724`dense`;;
 725        make unequal size columns to utilize more space
 726`nodense`;;
 727        make equal size columns
 728--
 729
 730column.branch::
 731        Specify whether to output branch listing in `git branch` in columns.
 732        See `column.ui` for details.
 733
 734column.clean::
 735        Specify the layout when list items in `git clean -i`, which always
 736        shows files and directories in columns. See `column.ui` for details.
 737
 738column.status::
 739        Specify whether to output untracked files in `git status` in columns.
 740        See `column.ui` for details.
 741
 742column.tag::
 743        Specify whether to output tag listing in `git tag` in columns.
 744        See `column.ui` for details.
 745
 746commit.cleanup::
 747        This setting overrides the default of the `--cleanup` option in
 748        `git commit`. See linkgit:git-commit[1] for details. Changing the
 749        default can be useful when you always want to keep lines that begin
 750        with comment character `#` in your log message, in which case you
 751        would do `git config commit.cleanup whitespace` (note that you will
 752        have to remove the help lines that begin with `#` in the commit log
 753        template yourself, if you do this).
 754
 755commit.gpgSign::
 756
 757        A boolean to specify whether all commits should be GPG signed.
 758        Use of this option when doing operations such as rebase can
 759        result in a large number of commits being signed. It may be
 760        convenient to use an agent to avoid typing your GPG passphrase
 761        several times.
 762
 763commit.status::
 764        A boolean to enable/disable inclusion of status information in the
 765        commit message template when using an editor to prepare the commit
 766        message.  Defaults to true.
 767
 768commit.template::
 769        Specify the pathname of a file to use as the template for
 770        new commit messages.
 771
 772commit.verbose::
 773        A boolean or int to specify the level of verbose with `git commit`.
 774        See linkgit:git-commit[1].
 775
 776credential.helper::
 777        Specify an external helper to be called when a username or
 778        password credential is needed; the helper may consult external
 779        storage to avoid prompting the user for the credentials. Note
 780        that multiple helpers may be defined. See linkgit:gitcredentials[7]
 781        for details.
 782
 783credential.useHttpPath::
 784        When acquiring credentials, consider the "path" component of an http
 785        or https URL to be important. Defaults to false. See
 786        linkgit:gitcredentials[7] for more information.
 787
 788credential.username::
 789        If no username is set for a network authentication, use this username
 790        by default. See credential.<context>.* below, and
 791        linkgit:gitcredentials[7].
 792
 793credential.<url>.*::
 794        Any of the credential.* options above can be applied selectively to
 795        some credentials. For example "credential.https://example.com.username"
 796        would set the default username only for https connections to
 797        example.com. See linkgit:gitcredentials[7] for details on how URLs are
 798        matched.
 799
 800credentialCache.ignoreSIGHUP::
 801        Tell git-credential-cache--daemon to ignore SIGHUP, instead of quitting.
 802
 803completion.commands::
 804        This is only used by git-completion.bash to add or remove
 805        commands from the list of completed commands. Normally only
 806        porcelain commands and a few select others are completed. You
 807        can add more commands, separated by space, in this
 808        variable. Prefixing the command with '-' will remove it from
 809        the existing list.
 810
 811include::diff-config.txt[]
 812
 813difftool.<tool>.path::
 814        Override the path for the given tool.  This is useful in case
 815        your tool is not in the PATH.
 816
 817difftool.<tool>.cmd::
 818        Specify the command to invoke the specified diff tool.
 819        The specified command is evaluated in shell with the following
 820        variables available:  'LOCAL' is set to the name of the temporary
 821        file containing the contents of the diff pre-image and 'REMOTE'
 822        is set to the name of the temporary file containing the contents
 823        of the diff post-image.
 824
 825difftool.prompt::
 826        Prompt before each invocation of the diff tool.
 827
 828fastimport.unpackLimit::
 829        If the number of objects imported by linkgit:git-fast-import[1]
 830        is below this limit, then the objects will be unpacked into
 831        loose object files.  However if the number of imported objects
 832        equals or exceeds this limit then the pack will be stored as a
 833        pack.  Storing the pack from a fast-import can make the import
 834        operation complete faster, especially on slow filesystems.  If
 835        not set, the value of `transfer.unpackLimit` is used instead.
 836
 837include::fetch-config.txt[]
 838
 839include::format-config.txt[]
 840
 841filter.<driver>.clean::
 842        The command which is used to convert the content of a worktree
 843        file to a blob upon checkin.  See linkgit:gitattributes[5] for
 844        details.
 845
 846filter.<driver>.smudge::
 847        The command which is used to convert the content of a blob
 848        object to a worktree file upon checkout.  See
 849        linkgit:gitattributes[5] for details.
 850
 851fsck.<msg-id>::
 852        During fsck git may find issues with legacy data which
 853        wouldn't be generated by current versions of git, and which
 854        wouldn't be sent over the wire if `transfer.fsckObjects` was
 855        set. This feature is intended to support working with legacy
 856        repositories containing such data.
 857+
 858Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
 859to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
 860to clone or fetch it set `fetch.fsck.<msg-id>`.
 861+
 862The rest of the documentation discusses `fsck.*` for brevity, but the
 863same applies for the corresponding `receive.fsck.*` and
 864`fetch.<msg-id>.*`. variables.
 865+
 866Unlike variables like `color.ui` and `core.editor` the
 867`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
 868fall back on the `fsck.<msg-id>` configuration if they aren't set. To
 869uniformly configure the same fsck settings in different circumstances
 870all three of them they must all set to the same values.
 871+
 872When `fsck.<msg-id>` is set, errors can be switched to warnings and
 873vice versa by configuring the `fsck.<msg-id>` setting where the
 874`<msg-id>` is the fsck message ID and the value is one of `error`,
 875`warn` or `ignore`. For convenience, fsck prefixes the error/warning
 876with the message ID, e.g. "missingEmail: invalid author/committer line
 877- missing email" means that setting `fsck.missingEmail = ignore` will
 878hide that issue.
 879+
 880In general, it is better to enumerate existing objects with problems
 881with `fsck.skipList`, instead of listing the kind of breakages these
 882problematic objects share to be ignored, as doing the latter will
 883allow new instances of the same breakages go unnoticed.
 884+
 885Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
 886doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
 887will only cause git to warn.
 888
 889fsck.skipList::
 890        The path to a list of object names (i.e. one unabbreviated SHA-1 per
 891        line) that are known to be broken in a non-fatal way and should
 892        be ignored. On versions of Git 2.20 and later comments ('#'), empty
 893        lines, and any leading and trailing whitespace is ignored. Everything
 894        but a SHA-1 per line will error out on older versions.
 895+
 896This feature is useful when an established project should be accepted
 897despite early commits containing errors that can be safely ignored
 898such as invalid committer email addresses.  Note: corrupt objects
 899cannot be skipped with this setting.
 900+
 901Like `fsck.<msg-id>` this variable has corresponding
 902`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
 903+
 904Unlike variables like `color.ui` and `core.editor` the
 905`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
 906fall back on the `fsck.skipList` configuration if they aren't set. To
 907uniformly configure the same fsck settings in different circumstances
 908all three of them they must all set to the same values.
 909+
 910Older versions of Git (before 2.20) documented that the object names
 911list should be sorted. This was never a requirement, the object names
 912could appear in any order, but when reading the list we tracked whether
 913the list was sorted for the purposes of an internal binary search
 914implementation, which could save itself some work with an already sorted
 915list. Unless you had a humongous list there was no reason to go out of
 916your way to pre-sort the list. After Git version 2.20 a hash implementation
 917is used instead, so there's now no reason to pre-sort the list.
 918
 919gc.aggressiveDepth::
 920        The depth parameter used in the delta compression
 921        algorithm used by 'git gc --aggressive'.  This defaults
 922        to 50.
 923
 924gc.aggressiveWindow::
 925        The window size parameter used in the delta compression
 926        algorithm used by 'git gc --aggressive'.  This defaults
 927        to 250.
 928
 929gc.auto::
 930        When there are approximately more than this many loose
 931        objects in the repository, `git gc --auto` will pack them.
 932        Some Porcelain commands use this command to perform a
 933        light-weight garbage collection from time to time.  The
 934        default value is 6700.  Setting this to 0 disables it.
 935
 936gc.autoPackLimit::
 937        When there are more than this many packs that are not
 938        marked with `*.keep` file in the repository, `git gc
 939        --auto` consolidates them into one larger pack.  The
 940        default value is 50.  Setting this to 0 disables it.
 941
 942gc.autoDetach::
 943        Make `git gc --auto` return immediately and run in background
 944        if the system supports it. Default is true.
 945
 946gc.bigPackThreshold::
 947        If non-zero, all packs larger than this limit are kept when
 948        `git gc` is run. This is very similar to `--keep-base-pack`
 949        except that all packs that meet the threshold are kept, not
 950        just the base pack. Defaults to zero. Common unit suffixes of
 951        'k', 'm', or 'g' are supported.
 952+
 953Note that if the number of kept packs is more than gc.autoPackLimit,
 954this configuration variable is ignored, all packs except the base pack
 955will be repacked. After this the number of packs should go below
 956gc.autoPackLimit and gc.bigPackThreshold should be respected again.
 957
 958gc.writeCommitGraph::
 959        If true, then gc will rewrite the commit-graph file when
 960        linkgit:git-gc[1] is run. When using linkgit:git-gc[1]
 961        '--auto' the commit-graph will be updated if housekeeping is
 962        required. Default is false. See linkgit:git-commit-graph[1]
 963        for details.
 964
 965gc.logExpiry::
 966        If the file gc.log exists, then `git gc --auto` will print
 967        its content and exit with status zero instead of running
 968        unless that file is more than 'gc.logExpiry' old.  Default is
 969        "1.day".  See `gc.pruneExpire` for more ways to specify its
 970        value.
 971
 972gc.packRefs::
 973        Running `git pack-refs` in a repository renders it
 974        unclonable by Git versions prior to 1.5.1.2 over dumb
 975        transports such as HTTP.  This variable determines whether
 976        'git gc' runs `git pack-refs`. This can be set to `notbare`
 977        to enable it within all non-bare repos or it can be set to a
 978        boolean value.  The default is `true`.
 979
 980gc.pruneExpire::
 981        When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
 982        Override the grace period with this config variable.  The value
 983        "now" may be used to disable this grace period and always prune
 984        unreachable objects immediately, or "never" may be used to
 985        suppress pruning.  This feature helps prevent corruption when
 986        'git gc' runs concurrently with another process writing to the
 987        repository; see the "NOTES" section of linkgit:git-gc[1].
 988
 989gc.worktreePruneExpire::
 990        When 'git gc' is run, it calls
 991        'git worktree prune --expire 3.months.ago'.
 992        This config variable can be used to set a different grace
 993        period. The value "now" may be used to disable the grace
 994        period and prune `$GIT_DIR/worktrees` immediately, or "never"
 995        may be used to suppress pruning.
 996
 997gc.reflogExpire::
 998gc.<pattern>.reflogExpire::
 999        'git reflog expire' removes reflog entries older than
1000        this time; defaults to 90 days. The value "now" expires all
1001        entries immediately, and "never" suppresses expiration
1002        altogether. With "<pattern>" (e.g.
1003        "refs/stash") in the middle the setting applies only to
1004        the refs that match the <pattern>.
1005
1006gc.reflogExpireUnreachable::
1007gc.<pattern>.reflogExpireUnreachable::
1008        'git reflog expire' removes reflog entries older than
1009        this time and are not reachable from the current tip;
1010        defaults to 30 days. The value "now" expires all entries
1011        immediately, and "never" suppresses expiration altogether.
1012        With "<pattern>" (e.g. "refs/stash")
1013        in the middle, the setting applies only to the refs that
1014        match the <pattern>.
1015
1016gc.rerereResolved::
1017        Records of conflicted merge you resolved earlier are
1018        kept for this many days when 'git rerere gc' is run.
1019        You can also use more human-readable "1.month.ago", etc.
1020        The default is 60 days.  See linkgit:git-rerere[1].
1021
1022gc.rerereUnresolved::
1023        Records of conflicted merge you have not resolved are
1024        kept for this many days when 'git rerere gc' is run.
1025        You can also use more human-readable "1.month.ago", etc.
1026        The default is 15 days.  See linkgit:git-rerere[1].
1027
1028include::gitcvs-config.txt[]
1029
1030gitweb.category::
1031gitweb.description::
1032gitweb.owner::
1033gitweb.url::
1034        See linkgit:gitweb[1] for description.
1035
1036gitweb.avatar::
1037gitweb.blame::
1038gitweb.grep::
1039gitweb.highlight::
1040gitweb.patches::
1041gitweb.pickaxe::
1042gitweb.remote_heads::
1043gitweb.showSizes::
1044gitweb.snapshot::
1045        See linkgit:gitweb.conf[5] for description.
1046
1047grep.lineNumber::
1048        If set to true, enable `-n` option by default.
1049
1050grep.column::
1051        If set to true, enable the `--column` option by default.
1052
1053grep.patternType::
1054        Set the default matching behavior. Using a value of 'basic', 'extended',
1055        'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
1056        `--fixed-strings`, or `--perl-regexp` option accordingly, while the
1057        value 'default' will return to the default matching behavior.
1058
1059grep.extendedRegexp::
1060        If set to true, enable `--extended-regexp` option by default. This
1061        option is ignored when the `grep.patternType` option is set to a value
1062        other than 'default'.
1063
1064grep.threads::
1065        Number of grep worker threads to use.
1066        See `grep.threads` in linkgit:git-grep[1] for more information.
1067
1068grep.fallbackToNoIndex::
1069        If set to true, fall back to git grep --no-index if git grep
1070        is executed outside of a git repository.  Defaults to false.
1071
1072gpg.program::
1073        Use this custom program instead of "`gpg`" found on `$PATH` when
1074        making or verifying a PGP signature. The program must support the
1075        same command-line interface as GPG, namely, to verify a detached
1076        signature, "`gpg --verify $file - <$signature`" is run, and the
1077        program is expected to signal a good signature by exiting with
1078        code 0, and to generate an ASCII-armored detached signature, the
1079        standard input of "`gpg -bsau $key`" is fed with the contents to be
1080        signed, and the program is expected to send the result to its
1081        standard output.
1082
1083gpg.format::
1084        Specifies which key format to use when signing with `--gpg-sign`.
1085        Default is "openpgp" and another possible value is "x509".
1086
1087gpg.<format>.program::
1088        Use this to customize the program used for the signing format you
1089        chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
1090        be used as a legacy synonym for `gpg.openpgp.program`. The default
1091        value for `gpg.x509.program` is "gpgsm".
1092
1093include::gui-config.txt[]
1094
1095guitool.<name>.cmd::
1096        Specifies the shell command line to execute when the corresponding item
1097        of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
1098        mandatory for every tool. The command is executed from the root of
1099        the working directory, and in the environment it receives the name of
1100        the tool as `GIT_GUITOOL`, the name of the currently selected file as
1101        'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
1102        the head is detached, 'CUR_BRANCH' is empty).
1103
1104guitool.<name>.needsFile::
1105        Run the tool only if a diff is selected in the GUI. It guarantees
1106        that 'FILENAME' is not empty.
1107
1108guitool.<name>.noConsole::
1109        Run the command silently, without creating a window to display its
1110        output.
1111
1112guitool.<name>.noRescan::
1113        Don't rescan the working directory for changes after the tool
1114        finishes execution.
1115
1116guitool.<name>.confirm::
1117        Show a confirmation dialog before actually running the tool.
1118
1119guitool.<name>.argPrompt::
1120        Request a string argument from the user, and pass it to the tool
1121        through the `ARGS` environment variable. Since requesting an
1122        argument implies confirmation, the 'confirm' option has no effect
1123        if this is enabled. If the option is set to 'true', 'yes', or '1',
1124        the dialog uses a built-in generic prompt; otherwise the exact
1125        value of the variable is used.
1126
1127guitool.<name>.revPrompt::
1128        Request a single valid revision from the user, and set the
1129        `REVISION` environment variable. In other aspects this option
1130        is similar to 'argPrompt', and can be used together with it.
1131
1132guitool.<name>.revUnmerged::
1133        Show only unmerged branches in the 'revPrompt' subdialog.
1134        This is useful for tools similar to merge or rebase, but not
1135        for things like checkout or reset.
1136
1137guitool.<name>.title::
1138        Specifies the title to use for the prompt dialog. The default
1139        is the tool name.
1140
1141guitool.<name>.prompt::
1142        Specifies the general prompt string to display at the top of
1143        the dialog, before subsections for 'argPrompt' and 'revPrompt'.
1144        The default value includes the actual command.
1145
1146help.browser::
1147        Specify the browser that will be used to display help in the
1148        'web' format. See linkgit:git-help[1].
1149
1150help.format::
1151        Override the default help format used by linkgit:git-help[1].
1152        Values 'man', 'info', 'web' and 'html' are supported. 'man' is
1153        the default. 'web' and 'html' are the same.
1154
1155help.autoCorrect::
1156        Automatically correct and execute mistyped commands after
1157        waiting for the given number of deciseconds (0.1 sec). If more
1158        than one command can be deduced from the entered text, nothing
1159        will be executed.  If the value of this option is negative,
1160        the corrected command will be executed immediately. If the
1161        value is 0 - the command will be just shown but not executed.
1162        This is the default.
1163
1164help.htmlPath::
1165        Specify the path where the HTML documentation resides. File system paths
1166        and URLs are supported. HTML pages will be prefixed with this path when
1167        help is displayed in the 'web' format. This defaults to the documentation
1168        path of your Git installation.
1169
1170http.proxy::
1171        Override the HTTP proxy, normally configured using the 'http_proxy',
1172        'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
1173        addition to the syntax understood by curl, it is possible to specify a
1174        proxy string with a user name but no password, in which case git will
1175        attempt to acquire one in the same way it does for other credentials. See
1176        linkgit:gitcredentials[7] for more information. The syntax thus is
1177        '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
1178        on a per-remote basis; see remote.<name>.proxy
1179
1180http.proxyAuthMethod::
1181        Set the method with which to authenticate against the HTTP proxy. This
1182        only takes effect if the configured proxy string contains a user name part
1183        (i.e. is of the form 'user@host' or 'user@host:port'). This can be
1184        overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
1185        Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
1186        variable.  Possible values are:
1187+
1188--
1189* `anyauth` - Automatically pick a suitable authentication method. It is
1190  assumed that the proxy answers an unauthenticated request with a 407
1191  status code and one or more Proxy-authenticate headers with supported
1192  authentication methods. This is the default.
1193* `basic` - HTTP Basic authentication
1194* `digest` - HTTP Digest authentication; this prevents the password from being
1195  transmitted to the proxy in clear text
1196* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
1197  of `curl(1)`)
1198* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
1199--
1200
1201http.emptyAuth::
1202        Attempt authentication without seeking a username or password.  This
1203        can be used to attempt GSS-Negotiate authentication without specifying
1204        a username in the URL, as libcurl normally requires a username for
1205        authentication.
1206
1207http.delegation::
1208        Control GSSAPI credential delegation. The delegation is disabled
1209        by default in libcurl since version 7.21.7. Set parameter to tell
1210        the server what it is allowed to delegate when it comes to user
1211        credentials. Used with GSS/kerberos. Possible values are:
1212+
1213--
1214* `none` - Don't allow any delegation.
1215* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
1216  Kerberos service ticket, which is a matter of realm policy.
1217* `always` - Unconditionally allow the server to delegate.
1218--
1219
1220
1221http.extraHeader::
1222        Pass an additional HTTP header when communicating with a server.  If
1223        more than one such entry exists, all of them are added as extra
1224        headers.  To allow overriding the settings inherited from the system
1225        config, an empty value will reset the extra headers to the empty list.
1226
1227http.cookieFile::
1228        The pathname of a file containing previously stored cookie lines,
1229        which should be used
1230        in the Git http session, if they match the server. The file format
1231        of the file to read cookies from should be plain HTTP headers or
1232        the Netscape/Mozilla cookie file format (see `curl(1)`).
1233        NOTE that the file specified with http.cookieFile is used only as
1234        input unless http.saveCookies is set.
1235
1236http.saveCookies::
1237        If set, store cookies received during requests to the file specified by
1238        http.cookieFile. Has no effect if http.cookieFile is unset.
1239
1240http.sslVersion::
1241        The SSL version to use when negotiating an SSL connection, if you
1242        want to force the default.  The available and default version
1243        depend on whether libcurl was built against NSS or OpenSSL and the
1244        particular configuration of the crypto library in use. Internally
1245        this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
1246        documentation for more details on the format of this option and
1247        for the ssl version supported. Actually the possible values of
1248        this option are:
1249
1250        - sslv2
1251        - sslv3
1252        - tlsv1
1253        - tlsv1.0
1254        - tlsv1.1
1255        - tlsv1.2
1256        - tlsv1.3
1257
1258+
1259Can be overridden by the `GIT_SSL_VERSION` environment variable.
1260To force git to use libcurl's default ssl version and ignore any
1261explicit http.sslversion option, set `GIT_SSL_VERSION` to the
1262empty string.
1263
1264http.sslCipherList::
1265  A list of SSL ciphers to use when negotiating an SSL connection.
1266  The available ciphers depend on whether libcurl was built against
1267  NSS or OpenSSL and the particular configuration of the crypto
1268  library in use.  Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
1269  option; see the libcurl documentation for more details on the format
1270  of this list.
1271+
1272Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
1273To force git to use libcurl's default cipher list and ignore any
1274explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
1275empty string.
1276
1277http.sslVerify::
1278        Whether to verify the SSL certificate when fetching or pushing
1279        over HTTPS. Defaults to true. Can be overridden by the
1280        `GIT_SSL_NO_VERIFY` environment variable.
1281
1282http.sslCert::
1283        File containing the SSL certificate when fetching or pushing
1284        over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
1285        variable.
1286
1287http.sslKey::
1288        File containing the SSL private key when fetching or pushing
1289        over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
1290        variable.
1291
1292http.sslCertPasswordProtected::
1293        Enable Git's password prompt for the SSL certificate.  Otherwise
1294        OpenSSL will prompt the user, possibly many times, if the
1295        certificate or private key is encrypted.  Can be overridden by the
1296        `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
1297
1298http.sslCAInfo::
1299        File containing the certificates to verify the peer with when
1300        fetching or pushing over HTTPS. Can be overridden by the
1301        `GIT_SSL_CAINFO` environment variable.
1302
1303http.sslCAPath::
1304        Path containing files with the CA certificates to verify the peer
1305        with when fetching or pushing over HTTPS. Can be overridden
1306        by the `GIT_SSL_CAPATH` environment variable.
1307
1308http.sslBackend::
1309        Name of the SSL backend to use (e.g. "openssl" or "schannel").
1310        This option is ignored if cURL lacks support for choosing the SSL
1311        backend at runtime.
1312
1313http.schannelCheckRevoke::
1314        Used to enforce or disable certificate revocation checks in cURL
1315        when http.sslBackend is set to "schannel". Defaults to `true` if
1316        unset. Only necessary to disable this if Git consistently errors
1317        and the message is about checking the revocation status of a
1318        certificate. This option is ignored if cURL lacks support for
1319        setting the relevant SSL option at runtime.
1320
1321http.schannelUseSSLCAInfo::
1322        As of cURL v7.60.0, the Secure Channel backend can use the
1323        certificate bundle provided via `http.sslCAInfo`, but that would
1324        override the Windows Certificate Store. Since this is not desirable
1325        by default, Git will tell cURL not to use that bundle by default
1326        when the `schannel` backend was configured via `http.sslBackend`,
1327        unless `http.schannelUseSSLCAInfo` overrides this behavior.
1328
1329http.pinnedpubkey::
1330        Public key of the https service. It may either be the filename of
1331        a PEM or DER encoded public key file or a string starting with
1332        'sha256//' followed by the base64 encoded sha256 hash of the
1333        public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
1334        exit with an error if this option is set but not supported by
1335        cURL.
1336
1337http.sslTry::
1338        Attempt to use AUTH SSL/TLS and encrypted data transfers
1339        when connecting via regular FTP protocol. This might be needed
1340        if the FTP server requires it for security reasons or you wish
1341        to connect securely whenever remote FTP server supports it.
1342        Default is false since it might trigger certificate verification
1343        errors on misconfigured servers.
1344
1345http.maxRequests::
1346        How many HTTP requests to launch in parallel. Can be overridden
1347        by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
1348
1349http.minSessions::
1350        The number of curl sessions (counted across slots) to be kept across
1351        requests. They will not be ended with curl_easy_cleanup() until
1352        http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
1353        value will be capped at 1. Defaults to 1.
1354
1355http.postBuffer::
1356        Maximum size in bytes of the buffer used by smart HTTP
1357        transports when POSTing data to the remote system.
1358        For requests larger than this buffer size, HTTP/1.1 and
1359        Transfer-Encoding: chunked is used to avoid creating a
1360        massive pack file locally.  Default is 1 MiB, which is
1361        sufficient for most requests.
1362
1363http.lowSpeedLimit, http.lowSpeedTime::
1364        If the HTTP transfer speed is less than 'http.lowSpeedLimit'
1365        for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
1366        Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
1367        `GIT_HTTP_LOW_SPEED_TIME` environment variables.
1368
1369http.noEPSV::
1370        A boolean which disables using of EPSV ftp command by curl.
1371        This can helpful with some "poor" ftp servers which don't
1372        support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV`
1373        environment variable. Default is false (curl will use EPSV).
1374
1375http.userAgent::
1376        The HTTP USER_AGENT string presented to an HTTP server.  The default
1377        value represents the version of the client Git such as git/1.7.1.
1378        This option allows you to override this value to a more common value
1379        such as Mozilla/4.0.  This may be necessary, for instance, if
1380        connecting through a firewall that restricts HTTP connections to a set
1381        of common USER_AGENT strings (but not including those like git/1.7.1).
1382        Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.
1383
1384http.followRedirects::
1385        Whether git should follow HTTP redirects. If set to `true`, git
1386        will transparently follow any redirect issued by a server it
1387        encounters. If set to `false`, git will treat all redirects as
1388        errors. If set to `initial`, git will follow redirects only for
1389        the initial request to a remote, but not for subsequent
1390        follow-up HTTP requests. Since git uses the redirected URL as
1391        the base for the follow-up requests, this is generally
1392        sufficient. The default is `initial`.
1393
1394http.<url>.*::
1395        Any of the http.* options above can be applied selectively to some URLs.
1396        For a config key to match a URL, each element of the config key is
1397        compared to that of the URL, in the following order:
1398+
1399--
1400. Scheme (e.g., `https` in `https://example.com/`). This field
1401  must match exactly between the config key and the URL.
1402
1403. Host/domain name (e.g., `example.com` in `https://example.com/`).
1404  This field must match between the config key and the URL. It is
1405  possible to specify a `*` as part of the host name to match all subdomains
1406  at this level. `https://*.example.com/` for example would match
1407  `https://foo.example.com/`, but not `https://foo.bar.example.com/`.
1408
1409. Port number (e.g., `8080` in `http://example.com:8080/`).
1410  This field must match exactly between the config key and the URL.
1411  Omitted port numbers are automatically converted to the correct
1412  default for the scheme before matching.
1413
1414. Path (e.g., `repo.git` in `https://example.com/repo.git`). The
1415  path field of the config key must match the path field of the URL
1416  either exactly or as a prefix of slash-delimited path elements.  This means
1417  a config key with path `foo/` matches URL path `foo/bar`.  A prefix can only
1418  match on a slash (`/`) boundary.  Longer matches take precedence (so a config
1419  key with path `foo/bar` is a better match to URL path `foo/bar` than a config
1420  key with just path `foo/`).
1421
1422. User name (e.g., `user` in `https://user@example.com/repo.git`). If
1423  the config key has a user name it must match the user name in the
1424  URL exactly. If the config key does not have a user name, that
1425  config key will match a URL with any user name (including none),
1426  but at a lower precedence than a config key with a user name.
1427--
1428+
1429The list above is ordered by decreasing precedence; a URL that matches
1430a config key's path is preferred to one that matches its user name. For example,
1431if the URL is `https://user@example.com/foo/bar` a config key match of
1432`https://example.com/foo` will be preferred over a config key match of
1433`https://user@example.com`.
1434+
1435All URLs are normalized before attempting any matching (the password part,
1436if embedded in the URL, is always ignored for matching purposes) so that
1437equivalent URLs that are simply spelled differently will match properly.
1438Environment variable settings always override any matches.  The URLs that are
1439matched against are those given directly to Git commands.  This means any URLs
1440visited as a result of a redirection do not participate in matching.
1441
1442ssh.variant::
1443        By default, Git determines the command line arguments to use
1444        based on the basename of the configured SSH command (configured
1445        using the environment variable `GIT_SSH` or `GIT_SSH_COMMAND` or
1446        the config setting `core.sshCommand`). If the basename is
1447        unrecognized, Git will attempt to detect support of OpenSSH
1448        options by first invoking the configured SSH command with the
1449        `-G` (print configuration) option and will subsequently use
1450        OpenSSH options (if that is successful) or no options besides
1451        the host and remote command (if it fails).
1452+
1453The config variable `ssh.variant` can be set to override this detection.
1454Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
1455`tortoiseplink`, `simple` (no options except the host and remote command).
1456The default auto-detection can be explicitly requested using the value
1457`auto`.  Any other value is treated as `ssh`.  This setting can also be
1458overridden via the environment variable `GIT_SSH_VARIANT`.
1459+
1460The current command-line parameters used for each variant are as
1461follows:
1462+
1463--
1464
1465* `ssh` - [-p port] [-4] [-6] [-o option] [username@]host command
1466
1467* `simple` - [username@]host command
1468
1469* `plink` or `putty` - [-P port] [-4] [-6] [username@]host command
1470
1471* `tortoiseplink` - [-P port] [-4] [-6] -batch [username@]host command
1472
1473--
1474+
1475Except for the `simple` variant, command-line parameters are likely to
1476change as git gains new features.
1477
1478i18n.commitEncoding::
1479        Character encoding the commit messages are stored in; Git itself
1480        does not care per se, but this information is necessary e.g. when
1481        importing commits from emails or in the gitk graphical history
1482        browser (and possibly at other places in the future or in other
1483        porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
1484
1485i18n.logOutputEncoding::
1486        Character encoding the commit messages are converted to when
1487        running 'git log' and friends.
1488
1489imap::
1490        The configuration variables in the 'imap' section are described
1491        in linkgit:git-imap-send[1].
1492
1493index.threads::
1494        Specifies the number of threads to spawn when loading the index.
1495        This is meant to reduce index load time on multiprocessor machines.
1496        Specifying 0 or 'true' will cause Git to auto-detect the number of
1497        CPU's and set the number of threads accordingly. Specifying 1 or
1498        'false' will disable multithreading. Defaults to 'true'.
1499
1500index.version::
1501        Specify the version with which new index files should be
1502        initialized.  This does not affect existing repositories.
1503
1504init.templateDir::
1505        Specify the directory from which templates will be copied.
1506        (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
1507
1508instaweb.browser::
1509        Specify the program that will be used to browse your working
1510        repository in gitweb. See linkgit:git-instaweb[1].
1511
1512instaweb.httpd::
1513        The HTTP daemon command-line to start gitweb on your working
1514        repository. See linkgit:git-instaweb[1].
1515
1516instaweb.local::
1517        If true the web server started by linkgit:git-instaweb[1] will
1518        be bound to the local IP (127.0.0.1).
1519
1520instaweb.modulePath::
1521        The default module path for linkgit:git-instaweb[1] to use
1522        instead of /usr/lib/apache2/modules.  Only used if httpd
1523        is Apache.
1524
1525instaweb.port::
1526        The port number to bind the gitweb httpd to. See
1527        linkgit:git-instaweb[1].
1528
1529interactive.singleKey::
1530        In interactive commands, allow the user to provide one-letter
1531        input with a single key (i.e., without hitting enter).
1532        Currently this is used by the `--patch` mode of
1533        linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
1534        linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
1535        setting is silently ignored if portable keystroke input
1536        is not available; requires the Perl module Term::ReadKey.
1537
1538interactive.diffFilter::
1539        When an interactive command (such as `git add --patch`) shows
1540        a colorized diff, git will pipe the diff through the shell
1541        command defined by this configuration variable. The command may
1542        mark up the diff further for human consumption, provided that it
1543        retains a one-to-one correspondence with the lines in the
1544        original diff. Defaults to disabled (no filtering).
1545
1546log.abbrevCommit::
1547        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
1548        linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
1549        override this option with `--no-abbrev-commit`.
1550
1551log.date::
1552        Set the default date-time mode for the 'log' command.
1553        Setting a value for log.date is similar to using 'git log''s
1554        `--date` option.  See linkgit:git-log[1] for details.
1555
1556log.decorate::
1557        Print out the ref names of any commits that are shown by the log
1558        command. If 'short' is specified, the ref name prefixes 'refs/heads/',
1559        'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
1560        specified, the full ref name (including prefix) will be printed.
1561        If 'auto' is specified, then if the output is going to a terminal,
1562        the ref names are shown as if 'short' were given, otherwise no ref
1563        names are shown. This is the same as the `--decorate` option
1564        of the `git log`.
1565
1566log.follow::
1567        If `true`, `git log` will act as if the `--follow` option was used when
1568        a single <path> is given.  This has the same limitations as `--follow`,
1569        i.e. it cannot be used to follow multiple files and does not work well
1570        on non-linear history.
1571
1572log.graphColors::
1573        A list of colors, separated by commas, that can be used to draw
1574        history lines in `git log --graph`.
1575
1576log.showRoot::
1577        If true, the initial commit will be shown as a big creation event.
1578        This is equivalent to a diff against an empty tree.
1579        Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
1580        normally hide the root commit will now show it. True by default.
1581
1582log.showSignature::
1583        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
1584        linkgit:git-whatchanged[1] assume `--show-signature`.
1585
1586log.mailmap::
1587        If true, makes linkgit:git-log[1], linkgit:git-show[1], and
1588        linkgit:git-whatchanged[1] assume `--use-mailmap`.
1589
1590mailinfo.scissors::
1591        If true, makes linkgit:git-mailinfo[1] (and therefore
1592        linkgit:git-am[1]) act by default as if the --scissors option
1593        was provided on the command-line. When active, this features
1594        removes everything from the message body before a scissors
1595        line (i.e. consisting mainly of ">8", "8<" and "-").
1596
1597mailmap.file::
1598        The location of an augmenting mailmap file. The default
1599        mailmap, located in the root of the repository, is loaded
1600        first, then the mailmap file pointed to by this variable.
1601        The location of the mailmap file may be in a repository
1602        subdirectory, or somewhere outside of the repository itself.
1603        See linkgit:git-shortlog[1] and linkgit:git-blame[1].
1604
1605mailmap.blob::
1606        Like `mailmap.file`, but consider the value as a reference to a
1607        blob in the repository. If both `mailmap.file` and
1608        `mailmap.blob` are given, both are parsed, with entries from
1609        `mailmap.file` taking precedence. In a bare repository, this
1610        defaults to `HEAD:.mailmap`. In a non-bare repository, it
1611        defaults to empty.
1612
1613man.viewer::
1614        Specify the programs that may be used to display help in the
1615        'man' format. See linkgit:git-help[1].
1616
1617man.<tool>.cmd::
1618        Specify the command to invoke the specified man viewer. The
1619        specified command is evaluated in shell with the man page
1620        passed as argument. (See linkgit:git-help[1].)
1621
1622man.<tool>.path::
1623        Override the path for the given tool that may be used to
1624        display help in the 'man' format. See linkgit:git-help[1].
1625
1626include::merge-config.txt[]
1627
1628mergetool.<tool>.path::
1629        Override the path for the given tool.  This is useful in case
1630        your tool is not in the PATH.
1631
1632mergetool.<tool>.cmd::
1633        Specify the command to invoke the specified merge tool.  The
1634        specified command is evaluated in shell with the following
1635        variables available: 'BASE' is the name of a temporary file
1636        containing the common base of the files to be merged, if available;
1637        'LOCAL' is the name of a temporary file containing the contents of
1638        the file on the current branch; 'REMOTE' is the name of a temporary
1639        file containing the contents of the file from the branch being
1640        merged; 'MERGED' contains the name of the file to which the merge
1641        tool should write the results of a successful merge.
1642
1643mergetool.<tool>.trustExitCode::
1644        For a custom merge command, specify whether the exit code of
1645        the merge command can be used to determine whether the merge was
1646        successful.  If this is not set to true then the merge target file
1647        timestamp is checked and the merge assumed to have been successful
1648        if the file has been updated, otherwise the user is prompted to
1649        indicate the success of the merge.
1650
1651mergetool.meld.hasOutput::
1652        Older versions of `meld` do not support the `--output` option.
1653        Git will attempt to detect whether `meld` supports `--output`
1654        by inspecting the output of `meld --help`.  Configuring
1655        `mergetool.meld.hasOutput` will make Git skip these checks and
1656        use the configured value instead.  Setting `mergetool.meld.hasOutput`
1657        to `true` tells Git to unconditionally use the `--output` option,
1658        and `false` avoids using `--output`.
1659
1660mergetool.keepBackup::
1661        After performing a merge, the original file with conflict markers
1662        can be saved as a file with a `.orig` extension.  If this variable
1663        is set to `false` then this file is not preserved.  Defaults to
1664        `true` (i.e. keep the backup files).
1665
1666mergetool.keepTemporaries::
1667        When invoking a custom merge tool, Git uses a set of temporary
1668        files to pass to the tool. If the tool returns an error and this
1669        variable is set to `true`, then these temporary files will be
1670        preserved, otherwise they will be removed after the tool has
1671        exited. Defaults to `false`.
1672
1673mergetool.writeToTemp::
1674        Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
1675        conflicting files in the worktree by default.  Git will attempt
1676        to use a temporary directory for these files when set `true`.
1677        Defaults to `false`.
1678
1679mergetool.prompt::
1680        Prompt before each invocation of the merge resolution program.
1681
1682notes.mergeStrategy::
1683        Which merge strategy to choose by default when resolving notes
1684        conflicts.  Must be one of `manual`, `ours`, `theirs`, `union`, or
1685        `cat_sort_uniq`.  Defaults to `manual`.  See "NOTES MERGE STRATEGIES"
1686        section of linkgit:git-notes[1] for more information on each strategy.
1687
1688notes.<name>.mergeStrategy::
1689        Which merge strategy to choose when doing a notes merge into
1690        refs/notes/<name>.  This overrides the more general
1691        "notes.mergeStrategy".  See the "NOTES MERGE STRATEGIES" section in
1692        linkgit:git-notes[1] for more information on the available strategies.
1693
1694notes.displayRef::
1695        The (fully qualified) refname from which to show notes when
1696        showing commit messages.  The value of this variable can be set
1697        to a glob, in which case notes from all matching refs will be
1698        shown.  You may also specify this configuration variable
1699        several times.  A warning will be issued for refs that do not
1700        exist, but a glob that does not match any refs is silently
1701        ignored.
1702+
1703This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
1704environment variable, which must be a colon separated list of refs or
1705globs.
1706+
1707The effective value of "core.notesRef" (possibly overridden by
1708GIT_NOTES_REF) is also implicitly added to the list of refs to be
1709displayed.
1710
1711notes.rewrite.<command>::
1712        When rewriting commits with <command> (currently `amend` or
1713        `rebase`) and this variable is set to `true`, Git
1714        automatically copies your notes from the original to the
1715        rewritten commit.  Defaults to `true`, but see
1716        "notes.rewriteRef" below.
1717
1718notes.rewriteMode::
1719        When copying notes during a rewrite (see the
1720        "notes.rewrite.<command>" option), determines what to do if
1721        the target commit already has a note.  Must be one of
1722        `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
1723        Defaults to `concatenate`.
1724+
1725This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
1726environment variable.
1727
1728notes.rewriteRef::
1729        When copying notes during a rewrite, specifies the (fully
1730        qualified) ref whose notes should be copied.  The ref may be a
1731        glob, in which case notes in all matching refs will be copied.
1732        You may also specify this configuration several times.
1733+
1734Does not have a default value; you must configure this variable to
1735enable note rewriting.  Set it to `refs/notes/commits` to enable
1736rewriting for the default commit notes.
1737+
1738This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
1739environment variable, which must be a colon separated list of refs or
1740globs.
1741
1742pack.window::
1743        The size of the window used by linkgit:git-pack-objects[1] when no
1744        window size is given on the command line. Defaults to 10.
1745
1746pack.depth::
1747        The maximum delta depth used by linkgit:git-pack-objects[1] when no
1748        maximum depth is given on the command line. Defaults to 50.
1749        Maximum value is 4095.
1750
1751pack.windowMemory::
1752        The maximum size of memory that is consumed by each thread
1753        in linkgit:git-pack-objects[1] for pack window memory when
1754        no limit is given on the command line.  The value can be
1755        suffixed with "k", "m", or "g".  When left unconfigured (or
1756        set explicitly to 0), there will be no limit.
1757
1758pack.compression::
1759        An integer -1..9, indicating the compression level for objects
1760        in a pack file. -1 is the zlib default. 0 means no
1761        compression, and 1..9 are various speed/size tradeoffs, 9 being
1762        slowest.  If not set,  defaults to core.compression.  If that is
1763        not set,  defaults to -1, the zlib default, which is "a default
1764        compromise between speed and compression (currently equivalent
1765        to level 6)."
1766+
1767Note that changing the compression level will not automatically recompress
1768all existing objects. You can force recompression by passing the -F option
1769to linkgit:git-repack[1].
1770
1771pack.island::
1772        An extended regular expression configuring a set of delta
1773        islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
1774        for details.
1775
1776pack.islandCore::
1777        Specify an island name which gets to have its objects be
1778        packed first. This creates a kind of pseudo-pack at the front
1779        of one pack, so that the objects from the specified island are
1780        hopefully faster to copy into any pack that should be served
1781        to a user requesting these objects. In practice this means
1782        that the island specified should likely correspond to what is
1783        the most commonly cloned in the repo. See also "DELTA ISLANDS"
1784        in linkgit:git-pack-objects[1].
1785
1786pack.deltaCacheSize::
1787        The maximum memory in bytes used for caching deltas in
1788        linkgit:git-pack-objects[1] before writing them out to a pack.
1789        This cache is used to speed up the writing object phase by not
1790        having to recompute the final delta result once the best match
1791        for all objects is found.  Repacking large repositories on machines
1792        which are tight with memory might be badly impacted by this though,
1793        especially if this cache pushes the system into swapping.
1794        A value of 0 means no limit. The smallest size of 1 byte may be
1795        used to virtually disable this cache. Defaults to 256 MiB.
1796
1797pack.deltaCacheLimit::
1798        The maximum size of a delta, that is cached in
1799        linkgit:git-pack-objects[1]. This cache is used to speed up the
1800        writing object phase by not having to recompute the final delta
1801        result once the best match for all objects is found.
1802        Defaults to 1000. Maximum value is 65535.
1803
1804pack.threads::
1805        Specifies the number of threads to spawn when searching for best
1806        delta matches.  This requires that linkgit:git-pack-objects[1]
1807        be compiled with pthreads otherwise this option is ignored with a
1808        warning. This is meant to reduce packing time on multiprocessor
1809        machines. The required amount of memory for the delta search window
1810        is however multiplied by the number of threads.
1811        Specifying 0 will cause Git to auto-detect the number of CPU's
1812        and set the number of threads accordingly.
1813
1814pack.indexVersion::
1815        Specify the default pack index version.  Valid values are 1 for
1816        legacy pack index used by Git versions prior to 1.5.2, and 2 for
1817        the new pack index with capabilities for packs larger than 4 GB
1818        as well as proper protection against the repacking of corrupted
1819        packs.  Version 2 is the default.  Note that version 2 is enforced
1820        and this config option ignored whenever the corresponding pack is
1821        larger than 2 GB.
1822+
1823If you have an old Git that does not understand the version 2 `*.idx` file,
1824cloning or fetching over a non native protocol (e.g. "http")
1825that will copy both `*.pack` file and corresponding `*.idx` file from the
1826other side may give you a repository that cannot be accessed with your
1827older version of Git. If the `*.pack` file is smaller than 2 GB, however,
1828you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
1829the `*.idx` file.
1830
1831pack.packSizeLimit::
1832        The maximum size of a pack.  This setting only affects
1833        packing to a file when repacking, i.e. the git:// protocol
1834        is unaffected.  It can be overridden by the `--max-pack-size`
1835        option of linkgit:git-repack[1].  Reaching this limit results
1836        in the creation of multiple packfiles; which in turn prevents
1837        bitmaps from being created.
1838        The minimum size allowed is limited to 1 MiB.
1839        The default is unlimited.
1840        Common unit suffixes of 'k', 'm', or 'g' are
1841        supported.
1842
1843pack.useBitmaps::
1844        When true, git will use pack bitmaps (if available) when packing
1845        to stdout (e.g., during the server side of a fetch). Defaults to
1846        true. You should not generally need to turn this off unless
1847        you are debugging pack bitmaps.
1848
1849pack.writeBitmaps (deprecated)::
1850        This is a deprecated synonym for `repack.writeBitmaps`.
1851
1852pack.writeBitmapHashCache::
1853        When true, git will include a "hash cache" section in the bitmap
1854        index (if one is written). This cache can be used to feed git's
1855        delta heuristics, potentially leading to better deltas between
1856        bitmapped and non-bitmapped objects (e.g., when serving a fetch
1857        between an older, bitmapped pack and objects that have been
1858        pushed since the last gc). The downside is that it consumes 4
1859        bytes per object of disk space, and that JGit's bitmap
1860        implementation does not understand it, causing it to complain if
1861        Git and JGit are used on the same repository. Defaults to false.
1862
1863pager.<cmd>::
1864        If the value is boolean, turns on or off pagination of the
1865        output of a particular Git subcommand when writing to a tty.
1866        Otherwise, turns on pagination for the subcommand using the
1867        pager specified by the value of `pager.<cmd>`.  If `--paginate`
1868        or `--no-pager` is specified on the command line, it takes
1869        precedence over this option.  To disable pagination for all
1870        commands, set `core.pager` or `GIT_PAGER` to `cat`.
1871
1872pretty.<name>::
1873        Alias for a --pretty= format string, as specified in
1874        linkgit:git-log[1]. Any aliases defined here can be used just
1875        as the built-in pretty formats could. For example,
1876        running `git config pretty.changelog "format:* %H %s"`
1877        would cause the invocation `git log --pretty=changelog`
1878        to be equivalent to running `git log "--pretty=format:* %H %s"`.
1879        Note that an alias with the same name as a built-in format
1880        will be silently ignored.
1881
1882protocol.allow::
1883        If set, provide a user defined default policy for all protocols which
1884        don't explicitly have a policy (`protocol.<name>.allow`).  By default,
1885        if unset, known-safe protocols (http, https, git, ssh, file) have a
1886        default policy of `always`, known-dangerous protocols (ext) have a
1887        default policy of `never`, and all other protocols have a default
1888        policy of `user`.  Supported policies:
1889+
1890--
1891
1892* `always` - protocol is always able to be used.
1893
1894* `never` - protocol is never able to be used.
1895
1896* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
1897  either unset or has a value of 1.  This policy should be used when you want a
1898  protocol to be directly usable by the user but don't want it used by commands which
1899  execute clone/fetch/push commands without user input, e.g. recursive
1900  submodule initialization.
1901
1902--
1903
1904protocol.<name>.allow::
1905        Set a policy to be used by protocol `<name>` with clone/fetch/push
1906        commands. See `protocol.allow` above for the available policies.
1907+
1908The protocol names currently used by git are:
1909+
1910--
1911  - `file`: any local file-based path (including `file://` URLs,
1912    or local paths)
1913
1914  - `git`: the anonymous git protocol over a direct TCP
1915    connection (or proxy, if configured)
1916
1917  - `ssh`: git over ssh (including `host:path` syntax,
1918    `ssh://`, etc).
1919
1920  - `http`: git over http, both "smart http" and "dumb http".
1921    Note that this does _not_ include `https`; if you want to configure
1922    both, you must do so individually.
1923
1924  - any external helpers are named by their protocol (e.g., use
1925    `hg` to allow the `git-remote-hg` helper)
1926--
1927
1928protocol.version::
1929        Experimental. If set, clients will attempt to communicate with a
1930        server using the specified protocol version.  If unset, no
1931        attempt will be made by the client to communicate using a
1932        particular protocol version, this results in protocol version 0
1933        being used.
1934        Supported versions:
1935+
1936--
1937
1938* `0` - the original wire protocol.
1939
1940* `1` - the original wire protocol with the addition of a version string
1941  in the initial response from the server.
1942
1943* `2` - link:technical/protocol-v2.html[wire protocol version 2].
1944
1945--
1946
1947include::pull-config.txt[]
1948
1949include::push-config.txt[]
1950
1951include::rebase-config.txt[]
1952
1953include::receive-config.txt[]
1954
1955remote.pushDefault::
1956        The remote to push to by default.  Overrides
1957        `branch.<name>.remote` for all branches, and is overridden by
1958        `branch.<name>.pushRemote` for specific branches.
1959
1960remote.<name>.url::
1961        The URL of a remote repository.  See linkgit:git-fetch[1] or
1962        linkgit:git-push[1].
1963
1964remote.<name>.pushurl::
1965        The push URL of a remote repository.  See linkgit:git-push[1].
1966
1967remote.<name>.proxy::
1968        For remotes that require curl (http, https and ftp), the URL to
1969        the proxy to use for that remote.  Set to the empty string to
1970        disable proxying for that remote.
1971
1972remote.<name>.proxyAuthMethod::
1973        For remotes that require curl (http, https and ftp), the method to use for
1974        authenticating against the proxy in use (probably set in
1975        `remote.<name>.proxy`). See `http.proxyAuthMethod`.
1976
1977remote.<name>.fetch::
1978        The default set of "refspec" for linkgit:git-fetch[1]. See
1979        linkgit:git-fetch[1].
1980
1981remote.<name>.push::
1982        The default set of "refspec" for linkgit:git-push[1]. See
1983        linkgit:git-push[1].
1984
1985remote.<name>.mirror::
1986        If true, pushing to this remote will automatically behave
1987        as if the `--mirror` option was given on the command line.
1988
1989remote.<name>.skipDefaultUpdate::
1990        If true, this remote will be skipped by default when updating
1991        using linkgit:git-fetch[1] or the `update` subcommand of
1992        linkgit:git-remote[1].
1993
1994remote.<name>.skipFetchAll::
1995        If true, this remote will be skipped by default when updating
1996        using linkgit:git-fetch[1] or the `update` subcommand of
1997        linkgit:git-remote[1].
1998
1999remote.<name>.receivepack::
2000        The default program to execute on the remote side when pushing.  See
2001        option --receive-pack of linkgit:git-push[1].
2002
2003remote.<name>.uploadpack::
2004        The default program to execute on the remote side when fetching.  See
2005        option --upload-pack of linkgit:git-fetch-pack[1].
2006
2007remote.<name>.tagOpt::
2008        Setting this value to --no-tags disables automatic tag following when
2009        fetching from remote <name>. Setting it to --tags will fetch every
2010        tag from remote <name>, even if they are not reachable from remote
2011        branch heads. Passing these flags directly to linkgit:git-fetch[1] can
2012        override this setting. See options --tags and --no-tags of
2013        linkgit:git-fetch[1].
2014
2015remote.<name>.vcs::
2016        Setting this to a value <vcs> will cause Git to interact with
2017        the remote with the git-remote-<vcs> helper.
2018
2019remote.<name>.prune::
2020        When set to true, fetching from this remote by default will also
2021        remove any remote-tracking references that no longer exist on the
2022        remote (as if the `--prune` option was given on the command line).
2023        Overrides `fetch.prune` settings, if any.
2024
2025remote.<name>.pruneTags::
2026        When set to true, fetching from this remote by default will also
2027        remove any local tags that no longer exist on the remote if pruning
2028        is activated in general via `remote.<name>.prune`, `fetch.prune` or
2029        `--prune`. Overrides `fetch.pruneTags` settings, if any.
2030+
2031See also `remote.<name>.prune` and the PRUNING section of
2032linkgit:git-fetch[1].
2033
2034remotes.<group>::
2035        The list of remotes which are fetched by "git remote update
2036        <group>".  See linkgit:git-remote[1].
2037
2038repack.useDeltaBaseOffset::
2039        By default, linkgit:git-repack[1] creates packs that use
2040        delta-base offset. If you need to share your repository with
2041        Git older than version 1.4.4, either directly or via a dumb
2042        protocol such as http, then you need to set this option to
2043        "false" and repack. Access from old Git versions over the
2044        native protocol are unaffected by this option.
2045
2046repack.packKeptObjects::
2047        If set to true, makes `git repack` act as if
2048        `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
2049        details. Defaults to `false` normally, but `true` if a bitmap
2050        index is being written (either via `--write-bitmap-index` or
2051        `repack.writeBitmaps`).
2052
2053repack.useDeltaIslands::
2054        If set to true, makes `git repack` act as if `--delta-islands`
2055        was passed. Defaults to `false`.
2056
2057repack.writeBitmaps::
2058        When true, git will write a bitmap index when packing all
2059        objects to disk (e.g., when `git repack -a` is run).  This
2060        index can speed up the "counting objects" phase of subsequent
2061        packs created for clones and fetches, at the cost of some disk
2062        space and extra time spent on the initial repack.  This has
2063        no effect if multiple packfiles are created.
2064        Defaults to false.
2065
2066rerere.autoUpdate::
2067        When set to true, `git-rerere` updates the index with the
2068        resulting contents after it cleanly resolves conflicts using
2069        previously recorded resolution.  Defaults to false.
2070
2071rerere.enabled::
2072        Activate recording of resolved conflicts, so that identical
2073        conflict hunks can be resolved automatically, should they be
2074        encountered again.  By default, linkgit:git-rerere[1] is
2075        enabled if there is an `rr-cache` directory under the
2076        `$GIT_DIR`, e.g. if "rerere" was previously used in the
2077        repository.
2078
2079reset.quiet::
2080        When set to true, 'git reset' will default to the '--quiet' option.
2081
2082include::sendemail-config.txt[]
2083
2084sequence.editor::
2085        Text editor used by `git rebase -i` for editing the rebase instruction file.
2086        The value is meant to be interpreted by the shell when it is used.
2087        It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
2088        When not configured the default commit message editor is used instead.
2089
2090showBranch.default::
2091        The default set of branches for linkgit:git-show-branch[1].
2092        See linkgit:git-show-branch[1].
2093
2094splitIndex.maxPercentChange::
2095        When the split index feature is used, this specifies the
2096        percent of entries the split index can contain compared to the
2097        total number of entries in both the split index and the shared
2098        index before a new shared index is written.
2099        The value should be between 0 and 100. If the value is 0 then
2100        a new shared index is always written, if it is 100 a new
2101        shared index is never written.
2102        By default the value is 20, so a new shared index is written
2103        if the number of entries in the split index would be greater
2104        than 20 percent of the total number of entries.
2105        See linkgit:git-update-index[1].
2106
2107splitIndex.sharedIndexExpire::
2108        When the split index feature is used, shared index files that
2109        were not modified since the time this variable specifies will
2110        be removed when a new shared index file is created. The value
2111        "now" expires all entries immediately, and "never" suppresses
2112        expiration altogether.
2113        The default value is "2.weeks.ago".
2114        Note that a shared index file is considered modified (for the
2115        purpose of expiration) each time a new split-index file is
2116        either created based on it or read from it.
2117        See linkgit:git-update-index[1].
2118
2119status.relativePaths::
2120        By default, linkgit:git-status[1] shows paths relative to the
2121        current directory. Setting this variable to `false` shows paths
2122        relative to the repository root (this was the default for Git
2123        prior to v1.5.4).
2124
2125status.short::
2126        Set to true to enable --short by default in linkgit:git-status[1].
2127        The option --no-short takes precedence over this variable.
2128
2129status.branch::
2130        Set to true to enable --branch by default in linkgit:git-status[1].
2131        The option --no-branch takes precedence over this variable.
2132
2133status.displayCommentPrefix::
2134        If set to true, linkgit:git-status[1] will insert a comment
2135        prefix before each output line (starting with
2136        `core.commentChar`, i.e. `#` by default). This was the
2137        behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
2138        Defaults to false.
2139
2140status.renameLimit::
2141        The number of files to consider when performing rename detection
2142        in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
2143        the value of diff.renameLimit.
2144
2145status.renames::
2146        Whether and how Git detects renames in linkgit:git-status[1] and
2147        linkgit:git-commit[1] .  If set to "false", rename detection is
2148        disabled. If set to "true", basic rename detection is enabled.
2149        If set to "copies" or "copy", Git will detect copies, as well.
2150        Defaults to the value of diff.renames.
2151
2152status.showStash::
2153        If set to true, linkgit:git-status[1] will display the number of
2154        entries currently stashed away.
2155        Defaults to false.
2156
2157status.showUntrackedFiles::
2158        By default, linkgit:git-status[1] and linkgit:git-commit[1] show
2159        files which are not currently tracked by Git. Directories which
2160        contain only untracked files, are shown with the directory name
2161        only. Showing untracked files means that Git needs to lstat() all
2162        the files in the whole repository, which might be slow on some
2163        systems. So, this variable controls how the commands displays
2164        the untracked files. Possible values are:
2165+
2166--
2167* `no` - Show no untracked files.
2168* `normal` - Show untracked files and directories.
2169* `all` - Show also individual files in untracked directories.
2170--
2171+
2172If this variable is not specified, it defaults to 'normal'.
2173This variable can be overridden with the -u|--untracked-files option
2174of linkgit:git-status[1] and linkgit:git-commit[1].
2175
2176status.submoduleSummary::
2177        Defaults to false.
2178        If this is set to a non zero number or true (identical to -1 or an
2179        unlimited number), the submodule summary will be enabled and a
2180        summary of commits for modified submodules will be shown (see
2181        --summary-limit option of linkgit:git-submodule[1]). Please note
2182        that the summary output command will be suppressed for all
2183        submodules when `diff.ignoreSubmodules` is set to 'all' or only
2184        for those submodules where `submodule.<name>.ignore=all`. The only
2185        exception to that rule is that status and commit will show staged
2186        submodule changes. To
2187        also view the summary for ignored submodules you can either use
2188        the --ignore-submodules=dirty command-line option or the 'git
2189        submodule summary' command, which shows a similar output but does
2190        not honor these settings.
2191
2192stash.showPatch::
2193        If this is set to true, the `git stash show` command without an
2194        option will show the stash entry in patch form.  Defaults to false.
2195        See description of 'show' command in linkgit:git-stash[1].
2196
2197stash.showStat::
2198        If this is set to true, the `git stash show` command without an
2199        option will show diffstat of the stash entry.  Defaults to true.
2200        See description of 'show' command in linkgit:git-stash[1].
2201
2202include::submodule-config.txt[]
2203
2204tag.forceSignAnnotated::
2205        A boolean to specify whether annotated tags created should be GPG signed.
2206        If `--annotate` is specified on the command line, it takes
2207        precedence over this option.
2208
2209tag.sort::
2210        This variable controls the sort ordering of tags when displayed by
2211        linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
2212        value of this variable will be used as the default.
2213
2214tar.umask::
2215        This variable can be used to restrict the permission bits of
2216        tar archive entries.  The default is 0002, which turns off the
2217        world write bit.  The special value "user" indicates that the
2218        archiving user's umask will be used instead.  See umask(2) and
2219        linkgit:git-archive[1].
2220
2221transfer.fsckObjects::
2222        When `fetch.fsckObjects` or `receive.fsckObjects` are
2223        not set, the value of this variable is used instead.
2224        Defaults to false.
2225+
2226When set, the fetch or receive will abort in the case of a malformed
2227object or a link to a nonexistent object. In addition, various other
2228issues are checked for, including legacy issues (see `fsck.<msg-id>`),
2229and potential security issues like the existence of a `.GIT` directory
2230or a malicious `.gitmodules` file (see the release notes for v2.2.1
2231and v2.17.1 for details). Other sanity and security checks may be
2232added in future releases.
2233+
2234On the receiving side, failing fsckObjects will make those objects
2235unreachable, see "QUARANTINE ENVIRONMENT" in
2236linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
2237instead be left unreferenced in the repository.
2238+
2239Due to the non-quarantine nature of the `fetch.fsckObjects`
2240implementation it can not be relied upon to leave the object store
2241clean like `receive.fsckObjects` can.
2242+
2243As objects are unpacked they're written to the object store, so there
2244can be cases where malicious objects get introduced even though the
2245"fetch" failed, only to have a subsequent "fetch" succeed because only
2246new incoming objects are checked, not those that have already been
2247written to the object store. That difference in behavior should not be
2248relied upon. In the future, such objects may be quarantined for
2249"fetch" as well.
2250+
2251For now, the paranoid need to find some way to emulate the quarantine
2252environment if they'd like the same protection as "push". E.g. in the
2253case of an internal mirror do the mirroring in two steps, one to fetch
2254the untrusted objects, and then do a second "push" (which will use the
2255quarantine) to another internal repo, and have internal clients
2256consume this pushed-to repository, or embargo internal fetches and
2257only allow them once a full "fsck" has run (and no new fetches have
2258happened in the meantime).
2259
2260transfer.hideRefs::
2261        String(s) `receive-pack` and `upload-pack` use to decide which
2262        refs to omit from their initial advertisements.  Use more than
2263        one definition to specify multiple prefix strings. A ref that is
2264        under the hierarchies listed in the value of this variable is
2265        excluded, and is hidden when responding to `git push` or `git
2266        fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
2267        program-specific versions of this config.
2268+
2269You may also include a `!` in front of the ref name to negate the entry,
2270explicitly exposing it, even if an earlier entry marked it as hidden.
2271If you have multiple hideRefs values, later entries override earlier ones
2272(and entries in more-specific config files override less-specific ones).
2273+
2274If a namespace is in use, the namespace prefix is stripped from each
2275reference before it is matched against `transfer.hiderefs` patterns.
2276For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
2277the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
2278is omitted from the advertisements but `refs/heads/master` and
2279`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
2280"have" lines. In order to match refs before stripping, add a `^` in front of
2281the ref name. If you combine `!` and `^`, `!` must be specified first.
2282+
2283Even if you hide refs, a client may still be able to steal the target
2284objects via the techniques described in the "SECURITY" section of the
2285linkgit:gitnamespaces[7] man page; it's best to keep private data in a
2286separate repository.
2287
2288transfer.unpackLimit::
2289        When `fetch.unpackLimit` or `receive.unpackLimit` are
2290        not set, the value of this variable is used instead.
2291        The default value is 100.
2292
2293uploadarchive.allowUnreachable::
2294        If true, allow clients to use `git archive --remote` to request
2295        any tree, whether reachable from the ref tips or not. See the
2296        discussion in the "SECURITY" section of
2297        linkgit:git-upload-archive[1] for more details. Defaults to
2298        `false`.
2299
2300uploadpack.hideRefs::
2301        This variable is the same as `transfer.hideRefs`, but applies
2302        only to `upload-pack` (and so affects only fetches, not pushes).
2303        An attempt to fetch a hidden ref by `git fetch` will fail.  See
2304        also `uploadpack.allowTipSHA1InWant`.
2305
2306uploadpack.allowTipSHA1InWant::
2307        When `uploadpack.hideRefs` is in effect, allow `upload-pack`
2308        to accept a fetch request that asks for an object at the tip
2309        of a hidden ref (by default, such a request is rejected).
2310        See also `uploadpack.hideRefs`.  Even if this is false, a client
2311        may be able to steal objects via the techniques described in the
2312        "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
2313        best to keep private data in a separate repository.
2314
2315uploadpack.allowReachableSHA1InWant::
2316        Allow `upload-pack` to accept a fetch request that asks for an
2317        object that is reachable from any ref tip. However, note that
2318        calculating object reachability is computationally expensive.
2319        Defaults to `false`.  Even if this is false, a client may be able
2320        to steal objects via the techniques described in the "SECURITY"
2321        section of the linkgit:gitnamespaces[7] man page; it's best to
2322        keep private data in a separate repository.
2323
2324uploadpack.allowAnySHA1InWant::
2325        Allow `upload-pack` to accept a fetch request that asks for any
2326        object at all.
2327        Defaults to `false`.
2328
2329uploadpack.keepAlive::
2330        When `upload-pack` has started `pack-objects`, there may be a
2331        quiet period while `pack-objects` prepares the pack. Normally
2332        it would output progress information, but if `--quiet` was used
2333        for the fetch, `pack-objects` will output nothing at all until
2334        the pack data begins. Some clients and networks may consider
2335        the server to be hung and give up. Setting this option instructs
2336        `upload-pack` to send an empty keepalive packet every
2337        `uploadpack.keepAlive` seconds. Setting this option to 0
2338        disables keepalive packets entirely. The default is 5 seconds.
2339
2340uploadpack.packObjectsHook::
2341        If this option is set, when `upload-pack` would run
2342        `git pack-objects` to create a packfile for a client, it will
2343        run this shell command instead.  The `pack-objects` command and
2344        arguments it _would_ have run (including the `git pack-objects`
2345        at the beginning) are appended to the shell command. The stdin
2346        and stdout of the hook are treated as if `pack-objects` itself
2347        was run. I.e., `upload-pack` will feed input intended for
2348        `pack-objects` to the hook, and expects a completed packfile on
2349        stdout.
2350+
2351Note that this configuration variable is ignored if it is seen in the
2352repository-level config (this is a safety measure against fetching from
2353untrusted repositories).
2354
2355uploadpack.allowFilter::
2356        If this option is set, `upload-pack` will support partial
2357        clone and partial fetch object filtering.
2358
2359uploadpack.allowRefInWant::
2360        If this option is set, `upload-pack` will support the `ref-in-want`
2361        feature of the protocol version 2 `fetch` command.  This feature
2362        is intended for the benefit of load-balanced servers which may
2363        not have the same view of what OIDs their refs point to due to
2364        replication delay.
2365
2366url.<base>.insteadOf::
2367        Any URL that starts with this value will be rewritten to
2368        start, instead, with <base>. In cases where some site serves a
2369        large number of repositories, and serves them with multiple
2370        access methods, and some users need to use different access
2371        methods, this feature allows people to specify any of the
2372        equivalent URLs and have Git automatically rewrite the URL to
2373        the best alternative for the particular user, even for a
2374        never-before-seen repository on the site.  When more than one
2375        insteadOf strings match a given URL, the longest match is used.
2376+
2377Note that any protocol restrictions will be applied to the rewritten
2378URL. If the rewrite changes the URL to use a custom protocol or remote
2379helper, you may need to adjust the `protocol.*.allow` config to permit
2380the request.  In particular, protocols you expect to use for submodules
2381must be set to `always` rather than the default of `user`. See the
2382description of `protocol.allow` above.
2383
2384url.<base>.pushInsteadOf::
2385        Any URL that starts with this value will not be pushed to;
2386        instead, it will be rewritten to start with <base>, and the
2387        resulting URL will be pushed to. In cases where some site serves
2388        a large number of repositories, and serves them with multiple
2389        access methods, some of which do not allow push, this feature
2390        allows people to specify a pull-only URL and have Git
2391        automatically use an appropriate URL to push, even for a
2392        never-before-seen repository on the site.  When more than one
2393        pushInsteadOf strings match a given URL, the longest match is
2394        used.  If a remote has an explicit pushurl, Git will ignore this
2395        setting for that remote.
2396
2397user.email::
2398        Your email address to be recorded in any newly created commits.
2399        Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
2400        `EMAIL` environment variables.  See linkgit:git-commit-tree[1].
2401
2402user.name::
2403        Your full name to be recorded in any newly created commits.
2404        Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
2405        environment variables.  See linkgit:git-commit-tree[1].
2406
2407user.useConfigOnly::
2408        Instruct Git to avoid trying to guess defaults for `user.email`
2409        and `user.name`, and instead retrieve the values only from the
2410        configuration. For example, if you have multiple email addresses
2411        and would like to use a different one for each repository, then
2412        with this configuration option set to `true` in the global config
2413        along with a name, Git will prompt you to set up an email before
2414        making new commits in a newly cloned repository.
2415        Defaults to `false`.
2416
2417user.signingKey::
2418        If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
2419        key you want it to automatically when creating a signed tag or
2420        commit, you can override the default selection with this variable.
2421        This option is passed unchanged to gpg's --local-user parameter,
2422        so you may specify a key using any method that gpg supports.
2423
2424versionsort.prereleaseSuffix (deprecated)::
2425        Deprecated alias for `versionsort.suffix`.  Ignored if
2426        `versionsort.suffix` is set.
2427
2428versionsort.suffix::
2429        Even when version sort is used in linkgit:git-tag[1], tagnames
2430        with the same base version but different suffixes are still sorted
2431        lexicographically, resulting e.g. in prerelease tags appearing
2432        after the main release (e.g. "1.0-rc1" after "1.0").  This
2433        variable can be specified to determine the sorting order of tags
2434        with different suffixes.
2435+
2436By specifying a single suffix in this variable, any tagname containing
2437that suffix will appear before the corresponding main release.  E.g. if
2438the variable is set to "-rc", then all "1.0-rcX" tags will appear before
2439"1.0".  If specified multiple times, once per suffix, then the order of
2440suffixes in the configuration will determine the sorting order of tagnames
2441with those suffixes.  E.g. if "-pre" appears before "-rc" in the
2442configuration, then all "1.0-preX" tags will be listed before any
2443"1.0-rcX" tags.  The placement of the main release tag relative to tags
2444with various suffixes can be determined by specifying the empty suffix
2445among those other suffixes.  E.g. if the suffixes "-rc", "", "-ck" and
2446"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
2447are listed first, followed by "v4.8", then "v4.8-ckX" and finally
2448"v4.8-bfsX".
2449+
2450If more than one suffixes match the same tagname, then that tagname will
2451be sorted according to the suffix which starts at the earliest position in
2452the tagname.  If more than one different matching suffixes start at
2453that earliest position, then that tagname will be sorted according to the
2454longest of those suffixes.
2455The sorting order between different suffixes is undefined if they are
2456in multiple config files.
2457
2458web.browser::
2459        Specify a web browser that may be used by some commands.
2460        Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
2461        may use it.
2462
2463worktree.guessRemote::
2464        With `add`, if no branch argument, and neither of `-b` nor
2465        `-B` nor `--detach` are given, the command defaults to
2466        creating a new branch from HEAD.  If `worktree.guessRemote` is
2467        set to true, `worktree add` tries to find a remote-tracking
2468        branch whose name uniquely matches the new branch name.  If
2469        such a branch exists, it is checked out and set as "upstream"
2470        for the new branch.  If no such match can be found, it falls
2471        back to creating a new branch from the current HEAD.