config.txt: move url.* to a separate file

[git] / Documentation / config.txt

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[]

include::config/man.txt[]

include::config/merge.txt[]

include::config/mergetool.txt[]

include::config/notes.txt[]

include::config/pack.txt[]

include::config/pager.txt[]

include::config/pretty.txt[]

include::config/protocol.txt[]

include::config/pull.txt[]

include::config/push.txt[]

include::config/rebase.txt[]

include::config/receive.txt[]

include::config/remote.txt[]

include::config/remotes.txt[]

include::config/repack.txt[]

include::config/rerere.txt[]

include::config/reset.txt[]

include::config/sendemail.txt[]

include::config/sequencer.txt[]

include::config/showbranch.txt[]

include::config/splitindex.txt[]

include::config/ssh.txt[]

include::config/status.txt[]

include::config/stash.txt[]

include::config/submodule.txt[]

include::config/tag.txt[]

include::config/transfer.txt[]

include::config/uploadarchive.txt[]

include::config/uploadpack.txt[]

include::config/url.txt[]

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.