CONFIGURATION FILE
------------------

The Git configuration file contains a number of variables that affect
the Git commands' behavior. The `.git/config` file in each repository
is used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.

The configuration variables are used by both the Git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive, allow only alphanumeric
characters and `-`, and must start with an alphabetic character.  Some
variables may appear multiple times; we say then that the variable is
multivalued.

Syntax
~~~~~~

The syntax is fairly flexible and permissive; whitespaces are mostly
ignored.  The '#' and ';' characters begin comments to the end of line,
blank lines are ignored.

The file consists of sections and variables.  A section begins with
the name of the section in square brackets and continues until the next
section begins.  Section names are case-insensitive.  Only alphanumeric
characters, `-` and `.` are allowed in section names.  Each variable
must belong to some section, which means that there must be a section
header before the first setting of a variable.

Sections can be further divided into subsections.  To begin a subsection
put its name in double quotes, separated by space from the section name,
in the section header, like in the example below:

--------
        [section "subsection"]

--------

Subsection names are case sensitive and can contain any characters except
newline and the null byte. Doublequote `"` and backslash can be included
by escaping them as `\"` and `\\`, respectively. Backslashes preceding
other characters are dropped when reading; for example, `\t` is read as
`t` and `\0` is read as `0` Section headers cannot span multiple lines.
Variables may belong directly to a section or to a given subsection. You
can have `[section]` if you have `[section "subsection"]`, but you don't
need to.

There is also a deprecated `[section.subsection]` syntax. With this
syntax, the subsection name is converted to lower-case and is also
compared case sensitively. These subsection names follow the same
restrictions as section names.

All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value' (or just 'name', which is a short-hand to say that
the variable is the boolean "true").
The variable names are case-insensitive, allow only alphanumeric characters
and `-`, and must start with an alphabetic character.

A line that defines a value can be continued to the next line by
ending it with a `\`; the backquote and the end-of-line are
stripped.  Leading whitespaces after 'name =', the remainder of the
line after the first comment character '#' or ';', and trailing
whitespaces of the line are discarded unless they are enclosed in
double quotes.  Internal whitespaces within the value are retained
verbatim.

Inside double quotes, double quote `"` and backslash `\` characters
must be escaped: use `\"` for `"` and `\\` for `\`.

The following escape sequences (beside `\"` and `\\`) are recognized:
`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
and `\b` for backspace (BS).  Other char escape sequences (including octal
escape sequences) are invalid.


Includes
~~~~~~~~

The `include` and `includeIf` sections allow you to include config
directives from another source. These sections behave identically to
each other with the exception that `includeIf` sections may be ignored
if their condition does not evaluate to true; see "Conditional includes"
below.

You can include a config file from another by setting the special
`include.path` (or `includeIf.*.path`) variable to the name of the file
to be included. The variable takes a pathname as its value, and is
subject to tilde expansion. These variables can be given multiple times.

The contents of the included file are inserted immediately, as if they
had been found at the location of the include directive. If the value of the
variable is a relative path, the path is considered to
be relative to the configuration file in which the include directive
was found.  See below for examples.

Conditional includes
~~~~~~~~~~~~~~~~~~~~

You can include a config file from another conditionally by setting a
`includeIf.<condition>.path` variable to the name of the file to be
included.

The condition starts with a keyword followed by a colon and some data
whose format and meaning depends on the keyword. Supported keywords
are:

`gitdir`::

        The data that follows the keyword `gitdir:` is used as a glob
        pattern. If the location of the .git directory matches the
        pattern, the include condition is met.
+
The .git location may be auto-discovered, or come from `$GIT_DIR`
environment variable. If the repository is auto discovered via a .git
file (e.g. from submodules, or a linked worktree), the .git location
would be the final location where the .git directory is, not where the
.git file is.
+
The pattern can contain standard globbing wildcards and two additional
ones, `**/` and `/**`, that can match multiple path components. Please
refer to linkgit:gitignore[5] for details. For convenience:

 * If the pattern starts with `~/`, `~` will be substituted with the
   content of the environment variable `HOME`.

 * If the pattern starts with `./`, it is replaced with the directory
   containing the current config file.

 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
   will be automatically prepended. For example, the pattern `foo/bar`
   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.

 * If the pattern ends with `/`, `**` will be automatically added. For
   example, the pattern `foo/` becomes `foo/**`. In other words, it
   matches "foo" and everything inside, recursively.

`gitdir/i`::
        This is the same as `gitdir` except that matching is done
        case-insensitively (e.g. on case-insensitive file sytems)

A few more notes on matching via `gitdir` and `gitdir/i`:

 * Symlinks in `$GIT_DIR` are not resolved before matching.

 * Both the symlink & realpath versions of paths will be matched
   outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
   /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
   will match.
+
This was not the case in the initial release of this feature in
v2.13.0, which only matched the realpath version. Configuration that
wants to be compatible with the initial release of this feature needs
to either specify only the realpath version, or both versions.

 * Note that "../" is not special and will match literally, which is
   unlikely what you want.

Example
~~~~~~~

        # Core variables
        [core]
                ; Don't trust file modes
                filemode = false

        # Our diff algorithm
        [diff]
                external = /usr/local/bin/diff-wrapper
                renames = true

        [branch "devel"]
                remote = origin
                merge = refs/heads/devel

        # Proxy settings
        [core]
                gitProxy="ssh" for "kernel.org"
                gitProxy=default-proxy ; for the rest

        [include]
                path = /path/to/foo.inc ; include by absolute path
                path = foo.inc ; find "foo.inc" relative to the current file
                path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory

        ; include if $GIT_DIR is /path/to/foo/.git
        [includeIf "gitdir:/path/to/foo/.git"]
                path = /path/to/foo.inc

        ; include for all repositories inside /path/to/group
        [includeIf "gitdir:/path/to/group/"]
                path = /path/to/foo.inc

        ; include for all repositories inside $HOME/to/group
        [includeIf "gitdir:~/to/group/"]
                path = /path/to/foo.inc

        ; relative paths are always relative to the including
        ; file (if the condition is true); their location is not
        ; affected by the condition
        [includeIf "gitdir:/path/to/group/"]
                path = foo.inc

Values
~~~~~~

Values of many variables are treated as a simple string, but there
are variables that take values of specific types and there are rules
as to how to spell them.

boolean::

       When a variable is said to take a boolean value, many
       synonyms are accepted for 'true' and 'false'; these are all
       case-insensitive.

        true;; Boolean true literals are `yes`, `on`, `true`,
                and `1`.  Also, a variable defined without `= <value>`
                is taken as true.

        false;; Boolean false literals are `no`, `off`, `false`,
                `0` and the empty string.
+
When converting a value to its canonical form using the `--type=bool` type
specifier, 'git config' will ensure that the output is "true" or
"false" (spelled in lowercase).

integer::
       The value for many variables that specify various sizes can
       be suffixed with `k`, `M`,... to mean "scale the number by
       1024", "by 1024x1024", etc.

color::
       The value for a variable that takes a color is a list of
       colors (at most two, one for foreground and one for background)
       and attributes (as many as you want), separated by spaces.
+
The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
`blue`, `magenta`, `cyan` and `white`.  The first color given is the
foreground; the second is the background.
+
Colors may also be given as numbers between 0 and 255; these use ANSI
256-color mode (but note that not all terminals may support this).  If
your terminal supports it, you may also specify 24-bit RGB values as
hex, like `#ff0ab3`.
+
The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
`italic`, and `strike` (for crossed-out or "strikethrough" letters).
The position of any attributes with respect to the colors
(before, after, or in between), doesn't matter. Specific attributes may
be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
`no-ul`, etc).
+
An empty color string produces no color effect at all. This can be used
to avoid coloring specific elements without disabling color entirely.
+
For git's pre-defined color slots, the attributes are meant to be reset
at the beginning of each item in the colored output. So setting
`color.decorate.branch` to `black` will paint that branch name in a
plain `black`, even if the previous thing on the same output line (e.g.
opening parenthesis before the list of branch names in `log --decorate`
output) is set to be painted with `bold` or some other attribute.
However, custom log formats may do more complicated and layered
coloring, and the negated forms may be useful there.

pathname::
        A variable that takes a pathname value can be given a
        string that begins with "`~/`" or "`~user/`", and the usual
        tilde expansion happens to such a string: `~/`
        is expanded to the value of `$HOME`, and `~user/` to the
        specified user's home directory.


Variables
~~~~~~~~~

Note that this list is non-comprehensive and not necessarily complete.
For command-specific variables, you will find a more detailed description
in the appropriate manual page.

Other git-related tools may and do use their own variables.  When
inventing new variables for use in your own tool, make sure their
names do not conflict with those that are used by Git itself and
other popular tools, and describe them in your documentation.

include::config/advice.txt[]

include::config/core.txt[]

include::config/add.txt[]

include::config/alias.txt[]

include::config/am.txt[]

include::config/apply.txt[]

include::config/blame.txt[]

include::config/branch.txt[]

include::config/browser.txt[]

include::config/checkout.txt[]

include::config/clean.txt[]

include::config/color.txt[]

include::config/column.txt[]

include::config/commit.txt[]

include::config/credential.txt[]

include::config/completion.txt[]

include::config/diff.txt[]

include::config/difftool.txt[]

include::config/fastimport.txt[]

include::config/fetch.txt[]

include::config/format.txt[]

include::config/filter.txt[]

include::config/fsck.txt[]

include::config/gc.txt[]

include::config/gitcvs.txt[]

include::config/gitweb.txt[]

include::config/grep.txt[]

include::config/gpg.txt[]

include::config/gui.txt[]

include::config/guitool.txt[]

include::config/help.txt[]

include::config/http.txt[]

include::config/i18n.txt[]

include::config/imap.txt[]

include::config/index.txt[]

include::config/init.txt[]

include::config/instaweb.txt[]

include::config/interactive.txt[]

include::config/log.txt[]

include::config/mailinfo.txt[]

include::config/mailmap.txt[]

man.viewer::
        Specify the programs that may be used to display help in the
        'man' format. See linkgit:git-help[1].

man.<tool>.cmd::
        Specify the command to invoke the specified man viewer. The
        specified command is evaluated in shell with the man page
        passed as argument. (See linkgit:git-help[1].)

man.<tool>.path::
        Override the path for the given tool that may be used to
        display help in the 'man' format. See linkgit:git-help[1].

include::merge-config.txt[]

mergetool.<tool>.path::
        Override the path for the given tool.  This is useful in case
        your tool is not in the PATH.

mergetool.<tool>.cmd::
        Specify the command to invoke the specified merge tool.  The
        specified command is evaluated in shell with the following
        variables available: 'BASE' is the name of a temporary file
        containing the common base of the files to be merged, if available;
        'LOCAL' is the name of a temporary file containing the contents of
        the file on the current branch; 'REMOTE' is the name of a temporary
        file containing the contents of the file from the branch being
        merged; 'MERGED' contains the name of the file to which the merge
        tool should write the results of a successful merge.

mergetool.<tool>.trustExitCode::
        For a custom merge command, specify whether the exit code of
        the merge command can be used to determine whether the merge was
        successful.  If this is not set to true then the merge target file
        timestamp is checked and the merge assumed to have been successful
        if the file has been updated, otherwise the user is prompted to
        indicate the success of the merge.

mergetool.meld.hasOutput::
        Older versions of `meld` do not support the `--output` option.
        Git will attempt to detect whether `meld` supports `--output`
        by inspecting the output of `meld --help`.  Configuring
        `mergetool.meld.hasOutput` will make Git skip these checks and
        use the configured value instead.  Setting `mergetool.meld.hasOutput`
        to `true` tells Git to unconditionally use the `--output` option,
        and `false` avoids using `--output`.

mergetool.keepBackup::
        After performing a merge, the original file with conflict markers
        can be saved as a file with a `.orig` extension.  If this variable
        is set to `false` then this file is not preserved.  Defaults to
        `true` (i.e. keep the backup files).

mergetool.keepTemporaries::
        When invoking a custom merge tool, Git uses a set of temporary
        files to pass to the tool. If the tool returns an error and this
        variable is set to `true`, then these temporary files will be
        preserved, otherwise they will be removed after the tool has
        exited. Defaults to `false`.

mergetool.writeToTemp::
        Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
        conflicting files in the worktree by default.  Git will attempt
        to use a temporary directory for these files when set `true`.
        Defaults to `false`.

mergetool.prompt::
        Prompt before each invocation of the merge resolution program.

notes.mergeStrategy::
        Which merge strategy to choose by default when resolving notes
        conflicts.  Must be one of `manual`, `ours`, `theirs`, `union`, or
        `cat_sort_uniq`.  Defaults to `manual`.  See "NOTES MERGE STRATEGIES"
        section of linkgit:git-notes[1] for more information on each strategy.

notes.<name>.mergeStrategy::
        Which merge strategy to choose when doing a notes merge into
        refs/notes/<name>.  This overrides the more general
        "notes.mergeStrategy".  See the "NOTES MERGE STRATEGIES" section in
        linkgit:git-notes[1] for more information on the available strategies.

notes.displayRef::
        The (fully qualified) refname from which to show notes when
        showing commit messages.  The value of this variable can be set
        to a glob, in which case notes from all matching refs will be
        shown.  You may also specify this configuration variable
        several times.  A warning will be issued for refs that do not
        exist, but a glob that does not match any refs is silently
        ignored.
+
This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
environment variable, which must be a colon separated list of refs or
globs.
+
The effective value of "core.notesRef" (possibly overridden by
GIT_NOTES_REF) is also implicitly added to the list of refs to be
displayed.

notes.rewrite.<command>::
        When rewriting commits with <command> (currently `amend` or
        `rebase`) and this variable is set to `true`, Git
        automatically copies your notes from the original to the
        rewritten commit.  Defaults to `true`, but see
        "notes.rewriteRef" below.

notes.rewriteMode::
        When copying notes during a rewrite (see the
        "notes.rewrite.<command>" option), determines what to do if
        the target commit already has a note.  Must be one of
        `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
        Defaults to `concatenate`.
+
This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
environment variable.

notes.rewriteRef::
        When copying notes during a rewrite, specifies the (fully
        qualified) ref whose notes should be copied.  The ref may be a
        glob, in which case notes in all matching refs will be copied.
        You may also specify this configuration several times.
+
Does not have a default value; you must configure this variable to
enable note rewriting.  Set it to `refs/notes/commits` to enable
rewriting for the default commit notes.
+
This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
environment variable, which must be a colon separated list of refs or
globs.

pack.window::
        The size of the window used by linkgit:git-pack-objects[1] when no
        window size is given on the command line. Defaults to 10.

pack.depth::
        The maximum delta depth used by linkgit:git-pack-objects[1] when no
        maximum depth is given on the command line. Defaults to 50.
        Maximum value is 4095.

pack.windowMemory::
        The maximum size of memory that is consumed by each thread
        in linkgit:git-pack-objects[1] for pack window memory when
        no limit is given on the command line.  The value can be
        suffixed with "k", "m", or "g".  When left unconfigured (or
        set explicitly to 0), there will be no limit.

pack.compression::
        An integer -1..9, indicating the compression level for objects
        in a pack file. -1 is the zlib default. 0 means no
        compression, and 1..9 are various speed/size tradeoffs, 9 being
        slowest.  If not set,  defaults to core.compression.  If that is
        not set,  defaults to -1, the zlib default, which is "a default
        compromise between speed and compression (currently equivalent
        to level 6)."
+
Note that changing the compression level will not automatically recompress
all existing objects. You can force recompression by passing the -F option
to linkgit:git-repack[1].

pack.island::
        An extended regular expression configuring a set of delta
        islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
        for details.

pack.islandCore::
        Specify an island name which gets to have its objects be
        packed first. This creates a kind of pseudo-pack at the front
        of one pack, so that the objects from the specified island are
        hopefully faster to copy into any pack that should be served
        to a user requesting these objects. In practice this means
        that the island specified should likely correspond to what is
        the most commonly cloned in the repo. See also "DELTA ISLANDS"
        in linkgit:git-pack-objects[1].

pack.deltaCacheSize::
        The maximum memory in bytes used for caching deltas in
        linkgit:git-pack-objects[1] before writing them out to a pack.
        This cache is used to speed up the writing object phase by not
        having to recompute the final delta result once the best match
        for all objects is found.  Repacking large repositories on machines
        which are tight with memory might be badly impacted by this though,
        especially if this cache pushes the system into swapping.
        A value of 0 means no limit. The smallest size of 1 byte may be
        used to virtually disable this cache. Defaults to 256 MiB.

pack.deltaCacheLimit::
        The maximum size of a delta, that is cached in
        linkgit:git-pack-objects[1]. This cache is used to speed up the
        writing object phase by not having to recompute the final delta
        result once the best match for all objects is found.
        Defaults to 1000. Maximum value is 65535.

pack.threads::
        Specifies the number of threads to spawn when searching for best
        delta matches.  This requires that linkgit:git-pack-objects[1]
        be compiled with pthreads otherwise this option is ignored with a
        warning. This is meant to reduce packing time on multiprocessor
        machines. The required amount of memory for the delta search window
        is however multiplied by the number of threads.
        Specifying 0 will cause Git to auto-detect the number of CPU's
        and set the number of threads accordingly.

pack.indexVersion::
        Specify the default pack index version.  Valid values are 1 for
        legacy pack index used by Git versions prior to 1.5.2, and 2 for
        the new pack index with capabilities for packs larger than 4 GB
        as well as proper protection against the repacking of corrupted
        packs.  Version 2 is the default.  Note that version 2 is enforced
        and this config option ignored whenever the corresponding pack is
        larger than 2 GB.
+
If you have an old Git that does not understand the version 2 `*.idx` file,
cloning or fetching over a non native protocol (e.g. "http")
that will copy both `*.pack` file and corresponding `*.idx` file from the
other side may give you a repository that cannot be accessed with your
older version of Git. If the `*.pack` file is smaller than 2 GB, however,
you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
the `*.idx` file.

pack.packSizeLimit::
        The maximum size of a pack.  This setting only affects
        packing to a file when repacking, i.e. the git:// protocol
        is unaffected.  It can be overridden by the `--max-pack-size`
        option of linkgit:git-repack[1].  Reaching this limit results
        in the creation of multiple packfiles; which in turn prevents
        bitmaps from being created.
        The minimum size allowed is limited to 1 MiB.
        The default is unlimited.
        Common unit suffixes of 'k', 'm', or 'g' are
        supported.

pack.useBitmaps::
        When true, git will use pack bitmaps (if available) when packing
        to stdout (e.g., during the server side of a fetch). Defaults to
        true. You should not generally need to turn this off unless
        you are debugging pack bitmaps.

pack.writeBitmaps (deprecated)::
        This is a deprecated synonym for `repack.writeBitmaps`.

pack.writeBitmapHashCache::
        When true, git will include a "hash cache" section in the bitmap
        index (if one is written). This cache can be used to feed git's
        delta heuristics, potentially leading to better deltas between
        bitmapped and non-bitmapped objects (e.g., when serving a fetch
        between an older, bitmapped pack and objects that have been
        pushed since the last gc). The downside is that it consumes 4
        bytes per object of disk space, and that JGit's bitmap
        implementation does not understand it, causing it to complain if
        Git and JGit are used on the same repository. Defaults to false.

pager.<cmd>::
        If the value is boolean, turns on or off pagination of the
        output of a particular Git subcommand when writing to a tty.
        Otherwise, turns on pagination for the subcommand using the
        pager specified by the value of `pager.<cmd>`.  If `--paginate`
        or `--no-pager` is specified on the command line, it takes
        precedence over this option.  To disable pagination for all
        commands, set `core.pager` or `GIT_PAGER` to `cat`.

pretty.<name>::
        Alias for a --pretty= format string, as specified in
        linkgit:git-log[1]. Any aliases defined here can be used just
        as the built-in pretty formats could. For example,
        running `git config pretty.changelog "format:* %H %s"`
        would cause the invocation `git log --pretty=changelog`
        to be equivalent to running `git log "--pretty=format:* %H %s"`.
        Note that an alias with the same name as a built-in format
        will be silently ignored.

protocol.allow::
        If set, provide a user defined default policy for all protocols which
        don't explicitly have a policy (`protocol.<name>.allow`).  By default,
        if unset, known-safe protocols (http, https, git, ssh, file) have a
        default policy of `always`, known-dangerous protocols (ext) have a
        default policy of `never`, and all other protocols have a default
        policy of `user`.  Supported policies:
+
--

* `always` - protocol is always able to be used.

* `never` - protocol is never able to be used.

* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
  either unset or has a value of 1.  This policy should be used when you want a
  protocol to be directly usable by the user but don't want it used by commands which
  execute clone/fetch/push commands without user input, e.g. recursive
  submodule initialization.

--

protocol.<name>.allow::
        Set a policy to be used by protocol `<name>` with clone/fetch/push
        commands. See `protocol.allow` above for the available policies.
+
The protocol names currently used by git are:
+
--
  - `file`: any local file-based path (including `file://` URLs,
    or local paths)

  - `git`: the anonymous git protocol over a direct TCP
    connection (or proxy, if configured)

  - `ssh`: git over ssh (including `host:path` syntax,
    `ssh://`, etc).

  - `http`: git over http, both "smart http" and "dumb http".
    Note that this does _not_ include `https`; if you want to configure
    both, you must do so individually.

  - any external helpers are named by their protocol (e.g., use
    `hg` to allow the `git-remote-hg` helper)
--

protocol.version::
        Experimental. If set, clients will attempt to communicate with a
        server using the specified protocol version.  If unset, no
        attempt will be made by the client to communicate using a
        particular protocol version, this results in protocol version 0
        being used.
        Supported versions:
+
--

* `0` - the original wire protocol.

* `1` - the original wire protocol with the addition of a version string
  in the initial response from the server.

* `2` - link:technical/protocol-v2.html[wire protocol version 2].

--

include::pull-config.txt[]

include::push-config.txt[]

include::rebase-config.txt[]

include::receive-config.txt[]

remote.pushDefault::
        The remote to push to by default.  Overrides
        `branch.<name>.remote` for all branches, and is overridden by
        `branch.<name>.pushRemote` for specific branches.

remote.<name>.url::
        The URL of a remote repository.  See linkgit:git-fetch[1] or
        linkgit:git-push[1].

remote.<name>.pushurl::
        The push URL of a remote repository.  See linkgit:git-push[1].

remote.<name>.proxy::
        For remotes that require curl (http, https and ftp), the URL to
        the proxy to use for that remote.  Set to the empty string to
        disable proxying for that remote.

remote.<name>.proxyAuthMethod::
        For remotes that require curl (http, https and ftp), the method to use for
        authenticating against the proxy in use (probably set in
        `remote.<name>.proxy`). See `http.proxyAuthMethod`.

remote.<name>.fetch::
        The default set of "refspec" for linkgit:git-fetch[1]. See
        linkgit:git-fetch[1].

remote.<name>.push::
        The default set of "refspec" for linkgit:git-push[1]. See
        linkgit:git-push[1].

remote.<name>.mirror::
        If true, pushing to this remote will automatically behave
        as if the `--mirror` option was given on the command line.

remote.<name>.skipDefaultUpdate::
        If true, this remote will be skipped by default when updating
        using linkgit:git-fetch[1] or the `update` subcommand of
        linkgit:git-remote[1].

remote.<name>.skipFetchAll::
        If true, this remote will be skipped by default when updating
        using linkgit:git-fetch[1] or the `update` subcommand of
        linkgit:git-remote[1].

remote.<name>.receivepack::
        The default program to execute on the remote side when pushing.  See
        option --receive-pack of linkgit:git-push[1].

remote.<name>.uploadpack::
        The default program to execute on the remote side when fetching.  See
        option --upload-pack of linkgit:git-fetch-pack[1].

remote.<name>.tagOpt::
        Setting this value to --no-tags disables automatic tag following when
        fetching from remote <name>. Setting it to --tags will fetch every
        tag from remote <name>, even if they are not reachable from remote
        branch heads. Passing these flags directly to linkgit:git-fetch[1] can
        override this setting. See options --tags and --no-tags of
        linkgit:git-fetch[1].

remote.<name>.vcs::
        Setting this to a value <vcs> will cause Git to interact with
        the remote with the git-remote-<vcs> helper.

remote.<name>.prune::
        When set to true, fetching from this remote by default will also
        remove any remote-tracking references that no longer exist on the
        remote (as if the `--prune` option was given on the command line).
        Overrides `fetch.prune` settings, if any.

remote.<name>.pruneTags::
        When set to true, fetching from this remote by default will also
        remove any local tags that no longer exist on the remote if pruning
        is activated in general via `remote.<name>.prune`, `fetch.prune` or
        `--prune`. Overrides `fetch.pruneTags` settings, if any.
+
See also `remote.<name>.prune` and the PRUNING section of
linkgit:git-fetch[1].

remotes.<group>::
        The list of remotes which are fetched by "git remote update
        <group>".  See linkgit:git-remote[1].

repack.useDeltaBaseOffset::
        By default, linkgit:git-repack[1] creates packs that use
        delta-base offset. If you need to share your repository with
        Git older than version 1.4.4, either directly or via a dumb
        protocol such as http, then you need to set this option to
        "false" and repack. Access from old Git versions over the
        native protocol are unaffected by this option.

repack.packKeptObjects::
        If set to true, makes `git repack` act as if
        `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
        details. Defaults to `false` normally, but `true` if a bitmap
        index is being written (either via `--write-bitmap-index` or
        `repack.writeBitmaps`).

repack.useDeltaIslands::
        If set to true, makes `git repack` act as if `--delta-islands`
        was passed. Defaults to `false`.

repack.writeBitmaps::
        When true, git will write a bitmap index when packing all
        objects to disk (e.g., when `git repack -a` is run).  This
        index can speed up the "counting objects" phase of subsequent
        packs created for clones and fetches, at the cost of some disk
        space and extra time spent on the initial repack.  This has
        no effect if multiple packfiles are created.
        Defaults to false.

rerere.autoUpdate::
        When set to true, `git-rerere` updates the index with the
        resulting contents after it cleanly resolves conflicts using
        previously recorded resolution.  Defaults to false.

rerere.enabled::
        Activate recording of resolved conflicts, so that identical
        conflict hunks can be resolved automatically, should they be
        encountered again.  By default, linkgit:git-rerere[1] is
        enabled if there is an `rr-cache` directory under the
        `$GIT_DIR`, e.g. if "rerere" was previously used in the
        repository.

reset.quiet::
        When set to true, 'git reset' will default to the '--quiet' option.

include::sendemail-config.txt[]

sequence.editor::
        Text editor used by `git rebase -i` for editing the rebase instruction file.
        The value is meant to be interpreted by the shell when it is used.
        It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
        When not configured the default commit message editor is used instead.

showBranch.default::
        The default set of branches for linkgit:git-show-branch[1].
        See linkgit:git-show-branch[1].

splitIndex.maxPercentChange::
        When the split index feature is used, this specifies the
        percent of entries the split index can contain compared to the
        total number of entries in both the split index and the shared
        index before a new shared index is written.
        The value should be between 0 and 100. If the value is 0 then
        a new shared index is always written, if it is 100 a new
        shared index is never written.
        By default the value is 20, so a new shared index is written
        if the number of entries in the split index would be greater
        than 20 percent of the total number of entries.
        See linkgit:git-update-index[1].

splitIndex.sharedIndexExpire::
        When the split index feature is used, shared index files that
        were not modified since the time this variable specifies will
        be removed when a new shared index file is created. The value
        "now" expires all entries immediately, and "never" suppresses
        expiration altogether.
        The default value is "2.weeks.ago".
        Note that a shared index file is considered modified (for the
        purpose of expiration) each time a new split-index file is
        either created based on it or read from it.
        See linkgit:git-update-index[1].

include::config/ssh.txt[]

status.relativePaths::
        By default, linkgit:git-status[1] shows paths relative to the
        current directory. Setting this variable to `false` shows paths
        relative to the repository root (this was the default for Git
        prior to v1.5.4).

status.short::
        Set to true to enable --short by default in linkgit:git-status[1].
        The option --no-short takes precedence over this variable.

status.branch::
        Set to true to enable --branch by default in linkgit:git-status[1].
        The option --no-branch takes precedence over this variable.

status.displayCommentPrefix::
        If set to true, linkgit:git-status[1] will insert a comment
        prefix before each output line (starting with
        `core.commentChar`, i.e. `#` by default). This was the
        behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
        Defaults to false.

status.renameLimit::
        The number of files to consider when performing rename detection
        in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
        the value of diff.renameLimit.

status.renames::
        Whether and how Git detects renames in linkgit:git-status[1] and
        linkgit:git-commit[1] .  If set to "false", rename detection is
        disabled. If set to "true", basic rename detection is enabled.
        If set to "copies" or "copy", Git will detect copies, as well.
        Defaults to the value of diff.renames.

status.showStash::
        If set to true, linkgit:git-status[1] will display the number of
        entries currently stashed away.
        Defaults to false.

status.showUntrackedFiles::
        By default, linkgit:git-status[1] and linkgit:git-commit[1] show
        files which are not currently tracked by Git. Directories which
        contain only untracked files, are shown with the directory name
        only. Showing untracked files means that Git needs to lstat() all
        the files in the whole repository, which might be slow on some
        systems. So, this variable controls how the commands displays
        the untracked files. Possible values are:
+
--
* `no` - Show no untracked files.
* `normal` - Show untracked files and directories.
* `all` - Show also individual files in untracked directories.
--
+
If this variable is not specified, it defaults to 'normal'.
This variable can be overridden with the -u|--untracked-files option
of linkgit:git-status[1] and linkgit:git-commit[1].

status.submoduleSummary::
        Defaults to false.
        If this is set to a non zero number or true (identical to -1 or an
        unlimited number), the submodule summary will be enabled and a
        summary of commits for modified submodules will be shown (see
        --summary-limit option of linkgit:git-submodule[1]). Please note
        that the summary output command will be suppressed for all
        submodules when `diff.ignoreSubmodules` is set to 'all' or only
        for those submodules where `submodule.<name>.ignore=all`. The only
        exception to that rule is that status and commit will show staged
        submodule changes. To
        also view the summary for ignored submodules you can either use
        the --ignore-submodules=dirty command-line option or the 'git
        submodule summary' command, which shows a similar output but does
        not honor these settings.

stash.showPatch::
        If this is set to true, the `git stash show` command without an
        option will show the stash entry in patch form.  Defaults to false.
        See description of 'show' command in linkgit:git-stash[1].

stash.showStat::
        If this is set to true, the `git stash show` command without an
        option will show diffstat of the stash entry.  Defaults to true.
        See description of 'show' command in linkgit:git-stash[1].

include::submodule-config.txt[]

tag.forceSignAnnotated::
        A boolean to specify whether annotated tags created should be GPG signed.
        If `--annotate` is specified on the command line, it takes
        precedence over this option.

tag.sort::
        This variable controls the sort ordering of tags when displayed by
        linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
        value of this variable will be used as the default.

tar.umask::
        This variable can be used to restrict the permission bits of
        tar archive entries.  The default is 0002, which turns off the
        world write bit.  The special value "user" indicates that the
        archiving user's umask will be used instead.  See umask(2) and
        linkgit:git-archive[1].

transfer.fsckObjects::
        When `fetch.fsckObjects` or `receive.fsckObjects` are
        not set, the value of this variable is used instead.
        Defaults to false.
+
When set, the fetch or receive will abort in the case of a malformed
object or a link to a nonexistent object. In addition, various other
issues are checked for, including legacy issues (see `fsck.<msg-id>`),
and potential security issues like the existence of a `.GIT` directory
or a malicious `.gitmodules` file (see the release notes for v2.2.1
and v2.17.1 for details). Other sanity and security checks may be
added in future releases.
+
On the receiving side, failing fsckObjects will make those objects
unreachable, see "QUARANTINE ENVIRONMENT" in
linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
instead be left unreferenced in the repository.
+
Due to the non-quarantine nature of the `fetch.fsckObjects`
implementation it can not be relied upon to leave the object store
clean like `receive.fsckObjects` can.
+
As objects are unpacked they're written to the object store, so there
can be cases where malicious objects get introduced even though the
"fetch" failed, only to have a subsequent "fetch" succeed because only
new incoming objects are checked, not those that have already been
written to the object store. That difference in behavior should not be
relied upon. In the future, such objects may be quarantined for
"fetch" as well.
+
For now, the paranoid need to find some way to emulate the quarantine
environment if they'd like the same protection as "push". E.g. in the
case of an internal mirror do the mirroring in two steps, one to fetch
the untrusted objects, and then do a second "push" (which will use the
quarantine) to another internal repo, and have internal clients
consume this pushed-to repository, or embargo internal fetches and
only allow them once a full "fsck" has run (and no new fetches have
happened in the meantime).

transfer.hideRefs::
        String(s) `receive-pack` and `upload-pack` use to decide which
        refs to omit from their initial advertisements.  Use more than
        one definition to specify multiple prefix strings. A ref that is
        under the hierarchies listed in the value of this variable is
        excluded, and is hidden when responding to `git push` or `git
        fetch`.  See `receive.hideRefs` and `uploadpack.hideRefs` for
        program-specific versions of this config.
+
You may also include a `!` in front of the ref name to negate the entry,
explicitly exposing it, even if an earlier entry marked it as hidden.
If you have multiple hideRefs values, later entries override earlier ones
(and entries in more-specific config files override less-specific ones).
+
If a namespace is in use, the namespace prefix is stripped from each
reference before it is matched against `transfer.hiderefs` patterns.
For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
is omitted from the advertisements but `refs/heads/master` and
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
"have" lines. In order to match refs before stripping, add a `^` in front of
the ref name. If you combine `!` and `^`, `!` must be specified first.
+
Even if you hide refs, a client may still be able to steal the target
objects via the techniques described in the "SECURITY" section of the
linkgit:gitnamespaces[7] man page; it's best to keep private data in a
separate repository.

transfer.unpackLimit::
        When `fetch.unpackLimit` or `receive.unpackLimit` are
        not set, the value of this variable is used instead.
        The default value is 100.

uploadarchive.allowUnreachable::
        If true, allow clients to use `git archive --remote` to request
        any tree, whether reachable from the ref tips or not. See the
        discussion in the "SECURITY" section of
        linkgit:git-upload-archive[1] for more details. Defaults to
        `false`.

uploadpack.hideRefs::
        This variable is the same as `transfer.hideRefs`, but applies
        only to `upload-pack` (and so affects only fetches, not pushes).
        An attempt to fetch a hidden ref by `git fetch` will fail.  See
        also `uploadpack.allowTipSHA1InWant`.

uploadpack.allowTipSHA1InWant::
        When `uploadpack.hideRefs` is in effect, allow `upload-pack`
        to accept a fetch request that asks for an object at the tip
        of a hidden ref (by default, such a request is rejected).
        See also `uploadpack.hideRefs`.  Even if this is false, a client
        may be able to steal objects via the techniques described in the
        "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
        best to keep private data in a separate repository.

uploadpack.allowReachableSHA1InWant::
        Allow `upload-pack` to accept a fetch request that asks for an
        object that is reachable from any ref tip. However, note that
        calculating object reachability is computationally expensive.
        Defaults to `false`.  Even if this is false, a client may be able
        to steal objects via the techniques described in the "SECURITY"
        section of the linkgit:gitnamespaces[7] man page; it's best to
        keep private data in a separate repository.

uploadpack.allowAnySHA1InWant::
        Allow `upload-pack` to accept a fetch request that asks for any
        object at all.
        Defaults to `false`.

uploadpack.keepAlive::
        When `upload-pack` has started `pack-objects`, there may be a
        quiet period while `pack-objects` prepares the pack. Normally
        it would output progress information, but if `--quiet` was used
        for the fetch, `pack-objects` will output nothing at all until
        the pack data begins. Some clients and networks may consider
        the server to be hung and give up. Setting this option instructs
        `upload-pack` to send an empty keepalive packet every
        `uploadpack.keepAlive` seconds. Setting this option to 0
        disables keepalive packets entirely. The default is 5 seconds.

uploadpack.packObjectsHook::
        If this option is set, when `upload-pack` would run
        `git pack-objects` to create a packfile for a client, it will
        run this shell command instead.  The `pack-objects` command and
        arguments it _would_ have run (including the `git pack-objects`
        at the beginning) are appended to the shell command. The stdin
        and stdout of the hook are treated as if `pack-objects` itself
        was run. I.e., `upload-pack` will feed input intended for
        `pack-objects` to the hook, and expects a completed packfile on
        stdout.
+
Note that this configuration variable is ignored if it is seen in the
repository-level config (this is a safety measure against fetching from
untrusted repositories).

uploadpack.allowFilter::
        If this option is set, `upload-pack` will support partial
        clone and partial fetch object filtering.

uploadpack.allowRefInWant::
        If this option is set, `upload-pack` will support the `ref-in-want`
        feature of the protocol version 2 `fetch` command.  This feature
        is intended for the benefit of load-balanced servers which may
        not have the same view of what OIDs their refs point to due to
        replication delay.

url.<base>.insteadOf::
        Any URL that starts with this value will be rewritten to
        start, instead, with <base>. In cases where some site serves a
        large number of repositories, and serves them with multiple
        access methods, and some users need to use different access
        methods, this feature allows people to specify any of the
        equivalent URLs and have Git automatically rewrite the URL to
        the best alternative for the particular user, even for a
        never-before-seen repository on the site.  When more than one
        insteadOf strings match a given URL, the longest match is used.
+
Note that any protocol restrictions will be applied to the rewritten
URL. If the rewrite changes the URL to use a custom protocol or remote
helper, you may need to adjust the `protocol.*.allow` config to permit
the request.  In particular, protocols you expect to use for submodules
must be set to `always` rather than the default of `user`. See the
description of `protocol.allow` above.

url.<base>.pushInsteadOf::
        Any URL that starts with this value will not be pushed to;
        instead, it will be rewritten to start with <base>, and the
        resulting URL will be pushed to. In cases where some site serves
        a large number of repositories, and serves them with multiple
        access methods, some of which do not allow push, this feature
        allows people to specify a pull-only URL and have Git
        automatically use an appropriate URL to push, even for a
        never-before-seen repository on the site.  When more than one
        pushInsteadOf strings match a given URL, the longest match is
        used.  If a remote has an explicit pushurl, Git will ignore this
        setting for that remote.

user.email::
        Your email address to be recorded in any newly created commits.
        Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
        `EMAIL` environment variables.  See linkgit:git-commit-tree[1].

user.name::
        Your full name to be recorded in any newly created commits.
        Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
        environment variables.  See linkgit:git-commit-tree[1].

user.useConfigOnly::
        Instruct Git to avoid trying to guess defaults for `user.email`
        and `user.name`, and instead retrieve the values only from the
        configuration. For example, if you have multiple email addresses
        and would like to use a different one for each repository, then
        with this configuration option set to `true` in the global config
        along with a name, Git will prompt you to set up an email before
        making new commits in a newly cloned repository.
        Defaults to `false`.

user.signingKey::
        If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
        key you want it to automatically when creating a signed tag or
        commit, you can override the default selection with this variable.
        This option is passed unchanged to gpg's --local-user parameter,
        so you may specify a key using any method that gpg supports.

versionsort.prereleaseSuffix (deprecated)::
        Deprecated alias for `versionsort.suffix`.  Ignored if
        `versionsort.suffix` is set.

versionsort.suffix::
        Even when version sort is used in linkgit:git-tag[1], tagnames
        with the same base version but different suffixes are still sorted
        lexicographically, resulting e.g. in prerelease tags appearing
        after the main release (e.g. "1.0-rc1" after "1.0").  This
        variable can be specified to determine the sorting order of tags
        with different suffixes.
+
By specifying a single suffix in this variable, any tagname containing
that suffix will appear before the corresponding main release.  E.g. if
the variable is set to "-rc", then all "1.0-rcX" tags will appear before
"1.0".  If specified multiple times, once per suffix, then the order of
suffixes in the configuration will determine the sorting order of tagnames
with those suffixes.  E.g. if "-pre" appears before "-rc" in the
configuration, then all "1.0-preX" tags will be listed before any
"1.0-rcX" tags.  The placement of the main release tag relative to tags
with various suffixes can be determined by specifying the empty suffix
among those other suffixes.  E.g. if the suffixes "-rc", "", "-ck" and
"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
are listed first, followed by "v4.8", then "v4.8-ckX" and finally
"v4.8-bfsX".
+
If more than one suffixes match the same tagname, then that tagname will
be sorted according to the suffix which starts at the earliest position in
the tagname.  If more than one different matching suffixes start at
that earliest position, then that tagname will be sorted according to the
longest of those suffixes.
The sorting order between different suffixes is undefined if they are
in multiple config files.

web.browser::
        Specify a web browser that may be used by some commands.
        Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
        may use it.

worktree.guessRemote::
        With `add`, if no branch argument, and neither of `-b` nor
        `-B` nor `--detach` are given, the command defaults to
        creating a new branch from HEAD.  If `worktree.guessRemote` is
        set to true, `worktree add` tries to find a remote-tracking
        branch whose name uniquely matches the new branch name.  If
        such a branch exists, it is checked out and set as "upstream"
        for the new branch.  If no such match can be found, it falls
        back to creating a new branch from the current HEAD.