Git - git-config Documentation

git-config last updated in 2.52.0

NAME

git-config - Get and set repository or global options

SYNOPSIS

git config list [<file-option>] [<display-option>] [--includes]
git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
git config set [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
git config unset [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
git config rename-section [<file-option>] <old-name> <new-name>
git config remove-section [<file-option>] <name>
git config edit [<file-option>]
git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]

DESCRIPTION

You can query/set/replace/unset options with this command. The name is actually the section and the key separated by a dot, and the value will be escaped.

Multiple lines can be added to an option by using the --append option. If you want to update or unset an option which can occur on multiple lines, --value=<pattern> (which is an extended regular expression, unless the --fixed-value option is given) needs to be given. Only the existing values that match the pattern are updated or unset. If you want to handle the lines that do not match the pattern, just prepend a single exclamation mark in front (see also EXAMPLES), but note that this only works when the --fixed-value option is not in use.

The --type=<type> option instructs git config to ensure that incoming and outgoing values are canonicalize-able under the given <type>. If no --type=<type> is given, no canonicalization will be performed. Callers may unset an existing --type specifier with --no-type.

When reading, the values are read from the system, global and repository local configuration files by default, and options --system, --global, --local, --worktree and --file <filename> can be used to tell the command to read from only that location (see FILES).

When writing, the new value is written to the repository local configuration file by default, and options --system, --global, --worktree, --file <filename> can be used to tell the command to write to that location (you can say --local but that is the default).

This command will fail with non-zero status upon error. Some exit codes are:

The section or key is invalid (ret=1),
no section or name was provided (ret=2),
the config file is invalid (ret=3),
the config file cannot be written (ret=4),
you try to unset an option which does not exist (ret=5),
you try to unset/set an option for which multiple lines match (ret=5), or
you try to use an invalid regexp (ret=6).

On success, the command returns the exit code 0.

A list of all available configuration variables can be obtained using the git help --config command.

COMMANDS

list: List all variables set in config file, along with their values.
get: Emits the value of the specified key. If key is present multiple times in the configuration, emits the last value. If --all is specified, emits all values associated with key. Returns error code 1 if key is not present.
set: Set value for one or more config options. By default, this command refuses to write multi-valued config options. Passing --all will replace all multi-valued config options with the new value, whereas --value= will replace all config options whose values match the given pattern.
unset: Unset value for one or more config options. By default, this command refuses to unset multi-valued keys. Passing --all will unset all multi-valued config options, whereas --value will unset all config options whose values match the given pattern.
rename-section: Rename the given section to a new name.
remove-section: Remove the given section from the configuration file.
edit: Opens an editor to modify the specified config file; either --system, --global, --local (default), --worktree, or --file <config-file>.

OPTIONS

--replace-all

Default behavior is to replace at most one line. This replaces all lines matching the key (and optionally --value=<pattern>).

--append

Adds a new line to the option without altering any existing values. This is the same as providing --value=^$ in set.

--comment <message>

Append a comment at the end of new or modified lines.

If <message> begins with one or more whitespaces followed by "", it is used as-is. If it begins with "", a space is prepended before it is used. Otherwise, a string " # " (a space followed by a hash followed by a space) is prepended to it. And the resulting string is placed immediately after the value defined for the variable. The <message> must not contain linefeed characters (no multi-line comments are permitted).

--all

With get, return all values for a multi-valued key.

--regexp

With get, interpret the name as a regular expression. Regular expression matching is currently case-sensitive and done against a canonicalized version of the key in which section and variable names are lowercased, but subsection names are not.

--url=<URL>

When given a two-part <name> as <section>.<key>, the value for <section>.<URL>.<key> whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for <section>.<key> is used as a fallback). When given just the <section> as name, do so for all the keys in the section and list them. Returns error code 1 if no value is found.

--global

For writing options: write to global ~/.gitconfig file rather than the repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the ~/.gitconfig file doesn’t.

For reading options: read only from global ~/.gitconfig and from $XDG_CONFIG_HOME/git/config rather than from all available files.

See also FILES.

--system

For writing options: write to system-wide $(prefix)/etc/gitconfig rather than the repository .git/config.

For reading options: read only from system-wide $(prefix)/etc/gitconfig rather than from all available files.

See also FILES.

--local

For writing options: write to the repository .git/config file. This is the default behavior.

For reading options: read only from the repository .git/config rather than from all available files.

See also FILES.

--worktree

Similar to --local except that $GIT_DIR/config.worktree is read from or written to if extensions.worktreeConfig is enabled. If not it’s the same as --local. Note that $GIT_DIR is equal to $GIT_COMMON_DIR for the main working tree, but is of the form $GIT_DIR/worktrees/<id>/ for other working trees. See git-worktree[1] to learn how to enable extensions.worktreeConfig.

-f <config-file>

--file <config-file>

For writing options: write to the specified file rather than the repository .git/config.

For reading options: read only from the specified file rather than from all available files.

See also FILES.

--blob <blob>

Similar to --file but use the given blob instead of a file. E.g. you can use master:.gitmodules to read values from the file .gitmodules in the master branch. See "SPECIFYING REVISIONS" section in gitrevisions[7] for a more complete list of ways to spell blob names.

--value=<pattern>

--no-value

With get, set, and unset, match only against <pattern>. The pattern is an extended regular expression unless --fixed-value is given.

Use --no-value to unset <pattern>.

--fixed-value

When used with --value=<pattern>, treat <pattern> as an exact string instead of a regular expression. This will restrict the name/value pairs that are matched to only those where the value is exactly equal to <pattern>.

--type <type>

git config will ensure that any input or output is valid under the given type constraint(s), and will canonicalize outgoing values in <type>'s canonical form.

Valid <type>'s include:

bool: canonicalize values true, yes,on, and positive numbers as "true", and values false, no, off and 0 as "false".
int: canonicalize values as simple decimal numbers. An optional suffix of k, m, or g will cause the value to be multiplied by 1024, 1048576, or 1073741824 upon input.
bool-or-int: canonicalize according to either bool or int, as described above.
path: canonicalize by expanding a leading ~ to the value of $HOME and ~user to the home directory for the specified user. This specifier has no effect when setting the value (but you can use git config section.variable ~/ from the command line to let your shell do the expansion.)
expiry-date: canonicalize by converting from a fixed or relative date-string to a timestamp. This specifier has no effect when setting the value.
color: When getting a value, canonicalize by converting to an ANSI color escape sequence. When setting a value, a sanity-check is performed to ensure that the given value is canonicalize-able as an ANSI color, but it is written as-is.

--bool

--int

--bool-or-int

--path

--expiry-date

Historical options for selecting a type specifier. Prefer instead --type (see above).

--no-type

Un-sets the previously set type specifier (if one was previously set). This option requests that git config not canonicalize the retrieved variable. --no-type has no effect without --type=<type> or --<type>.

-z

--null

For all options that output values and/or keys, always end values with the null character (instead of a newline). Use newline instead as a delimiter between key and value. This allows for secure parsing of the output without getting confused e.g. by values that contain line breaks.

--name-only

Output only the names of config variables for list or get.

--show-names

--no-show-names

With get, show config keys in addition to their values. The default is --no-show-names unless --url is given and there are no subsections in <name>.

--show-origin

Augment the output of all queried config options with the origin type (file, standard input, blob, command line) and the actual origin (config file path, ref, or blob id if applicable).

--show-scope

Similar to --show-origin in that it augments the output of all queried config options with the scope of that value (worktree, local, global, system, command).

--get-colorbool <name> [<stdout-is-tty>]

Find the color setting for <name> (e.g. color.diff) and output "true" or "false". <stdout-is-tty> should be either "true" or "false", and is taken into account when configuration says "auto". If <stdout-is-tty> is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise. When the color setting for name is undefined, the command uses color.ui as fallback.

--includes

--no-includes

Respect include.* directives in config files when looking up values. Defaults to off when a specific file is given (e.g., using --file, --global, etc) and on when searching all config files.

--default <value>

When using get, and the requested variable is not found, behave as if <value> were the value assigned to that variable.

DEPRECATED MODES

The following modes have been deprecated in favor of subcommands. It is recommended to migrate to the new syntax.

git config <name>: Replaced by git config get <name>.
git config <name> <value> [<value-pattern>]: Replaced by git config set [--value=<pattern>] <name> <value>.
-l
--list: Replaced by git config list.
--get <name> [<value-pattern>]: Replaced by git config get [--value=<pattern>] <name>.
--get-all <name> [<value-pattern>]: Replaced by git config get [--value=<pattern>] --all <name>.
--get-regexp <name-regexp>: Replaced by git config get --all --show-names --regexp <name-regexp>.
--get-urlmatch <name> <URL>: Replaced by git config get --all --show-names --url=<URL> <name>.
--get-color <name> [<default>]: Replaced by git config get --type=color [--default=<default>] <name>.
--add <name> <value>: Replaced by git config set --append <name> <value>.
--unset <name> [<value-pattern>]: Replaced by git config unset [--value=<pattern>] <name>.
--unset-all <name> [<value-pattern>]: Replaced by git config unset [--value=<pattern>] --all <name>.
--rename-section <old-name> <new-name>: Replaced by git config rename-section <old-name> <new-name>.
--remove-section <name>: Replaced by git config remove-section <name>.
-e
--edit: Replaced by git config edit.

CONFIGURATION

pager.config is only respected when listing configuration, i.e., when using list or get which may return multiple results. The default is to use a pager.

FILES

By default, git config will read configuration options from multiple files:

$(prefix)/etc/gitconfig: System-wide configuration file.
$XDG_CONFIG_HOME/git/config
~/.gitconfig: User-specific configuration files. When the XDG_CONFIG_HOME environment variable is not set or empty, $HOME/.config/ is used as $XDG_CONFIG_HOME.

These are also called "global" configuration files. If both files exist, both files are read in the order given above.
$GIT_DIR/config: Repository specific configuration file.
$GIT_DIR/config.worktree: This is optional and is only searched when extensions.worktreeConfig is present in $GIT_DIR/config.

You may also provide additional configuration parameters when running any git command by using the -c option. See git[1] for details.

Options will be read from all of these files that are available. If the global or the system-wide configuration files are missing or unreadable they will be ignored. If the repository configuration file is missing or unreadable, git config will exit with a non-zero error code. An error message is produced if the file is unreadable, but not if it is missing.

The files are read in the order given above, with last value found taking precedence over values read earlier. When multiple values are taken then all values of a key from all files will be used.

By default, options are only written to the repository specific configuration file. Note that this also affects options like set and unset. git config will only ever change one file at a time.

You can limit which configuration sources are read from or written to by specifying the path of a file with the --file option, or by specifying a configuration scope with --system, --global, --local, or --worktree. For more, see OPTIONS above.

SCOPES

Each configuration source falls within a configuration scope. The scopes are:

system: $(prefix)/etc/gitconfig
global: $XDG_CONFIG_HOME/git/config

~/.gitconfig
local: $GIT_DIR/config
worktree: $GIT_DIR/config.worktree
command: GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see ENVIRONMENT below)

the -c option

With the exception of command, each scope corresponds to a command line option: --system, --global, --local, --worktree.

When reading options, specifying a scope will only read options from the files within that scope. When writing options, specifying a scope will write to the files within that scope (instead of the repository specific configuration file). See OPTIONS above for a complete description.

Most configuration options are respected regardless of the scope it is defined in, but some options are only respected in certain scopes. See the respective option’s documentation for the full details.

Protected configuration

Protected configuration refers to the system, global, and command scopes. For security reasons, certain options are only respected when they are specified in protected configuration, and ignored otherwise.

Git treats these scopes as if they are controlled by the user or a trusted administrator. This is because an attacker who controls these scopes can do substantial harm without using Git, so it is assumed that the user’s environment protects these scopes against attackers.

ENVIRONMENT

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Take the configuration from the given files instead from global or system-level configuration. See git[1] for details.
GIT_CONFIG_NOSYSTEM: Whether to skip reading settings from the system-wide $(prefix)/etc/gitconfig file. See git[1] for details.

See also FILES.

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>: If GIT_CONFIG_COUNT is set to a positive number, all environment pairs GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be added to the process’s runtime configuration. The config pairs are zero-indexed. Any missing key or value is treated as an error. An empty GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no pairs are processed. These environment variables will override values in configuration files, but will be overridden by any explicit options passed via git -c.

This is useful for cases where you want to spawn multiple git commands with a common configuration but cannot depend on a configuration file, for example when writing scripts.
GIT_CONFIG: If no --file option is provided to git config, use the file given by GIT_CONFIG as if it were provided via --file. This variable has no effect on other Git commands, and is mostly for historical compatibility; there is generally no reason to use it instead of the --file option.

EXAMPLES

Given a .git/config like this:

#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#

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

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

; Proxy settings
[core]
	gitproxy=proxy-command for kernel.org
	gitproxy=default-proxy ; for all the rest

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
	cookieFile = /tmp/cookie.txt

you can set the filemode to true with

% git config set core.filemode true

The hypothetical proxy command entries actually have a postfix to discern what URL they apply to. Here is how to change the entry for kernel.org to "ssh".

% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'

This makes sure that only the key/value pair for kernel.org is replaced.

To delete the entry for renames, do

% git config unset diff.renames

If you want to delete an entry for a multivar (like core.gitproxy above), you have to provide a regex matching the value of exactly one line.

To query the value for a given key, do

% git config get core.filemode

or, to query a multivar:

% git config get --value="for kernel.org$" core.gitproxy

If you want to know all the values for a multivar, do:

% git config get --all --show-names core.gitproxy

If you like to live dangerously, you can replace all core.gitproxy by a new one with

% git config set --all core.gitproxy ssh

However, if you really only want to replace the line for the default proxy, i.e. the one without a "for …" postfix, do something like this:

% git config set --value='! for ' core.gitproxy ssh

To actually match only values with an exclamation mark, you have to

% git config set --value='[!]' section.key value

To add a new proxy, without altering any of the existing ones, use

% git config set --append core.gitproxy '"proxy-command" for example.com'

An example to use customized color from the configuration in your script:

#!/bin/sh
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
RESET=$(git config get --type=color --default="reset" "")
echo "${WS}your whitespace color or blue reverse${RESET}"

For URLs in https://weak.example.com, http.sslVerify is set to false, while it is set to true for all others:

% git config get --type=bool --url=https://good.example.com http.sslverify
true
% git config get --type=bool --url=https://weak.example.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt
http.sslverify false

CONFIGURATION FILE

The Git configuration file contains a number of variables that affect the Git commands' behavior. The files .git/config and optionally config.worktree (see the "CONFIGURATION FILE" section of git-worktree[1]) in each repository are 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 porcelain commands. 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. Whitespace characters, which in this context are the space character (SP) and the horizontal tabulation (HT), 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.

Whitespace characters surrounding name, = and value are discarded. Internal whitespace characters within value are retained verbatim. Comments starting with either # or ; and extending to the end of line are discarded. A line that defines a value can be continued to the next line by ending it with a backslash (\); the backslash and the end-of-line characters are discarded.

If value needs to contain leading or trailing whitespace characters, it must be enclosed in double quotation marks ("). Inside double quotation marks, 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 conditionally include a config file from another by setting an 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 and a colon 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 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 systems)

onbranch

The data that follows the keyword onbranch and a colon is taken to be a pattern with standard globbing wildcards and two additional ones, **/ and /**, that can match multiple path components. If we are in a worktree where the name of the branch that is currently checked out matches the pattern, the include condition is met.

If the pattern ends with /, ** will be automatically added. For example, the pattern foo/ becomes foo/**. In other words, it matches all branches that begin with foo/. This is useful if your branches are organized hierarchically and you would like to apply a configuration to all the branches in that hierarchy.

hasconfig:remote.*.url

The data that follows this keyword and a colon is taken to be a pattern with standard globbing wildcards and two additional ones, **/ and /**, that can match multiple components. The first time this keyword is seen, the rest of the config files will be scanned for remote URLs (without applying any values). If there exists at least one remote URL that matches this pattern, the include condition is met.

Files included by this option (directly or indirectly) are not allowed to contain remote URLs.

Note that unlike other includeIf conditions, resolving this condition relies on information that is not yet known at the point of reading the condition. A typical use case is this option being present as a system-level or global-level config, and the remote URL being in a local-level config; hence the need to scan ahead when resolving this condition. In order to avoid the chicken-and-egg problem in which potentially-included files can affect whether such files are potentially included, Git breaks the cycle by prohibiting these files from affecting the resolution of these conditions (thus, prohibiting them from declaring remote URLs).

As for the naming of this keyword, it is for forwards compatibility with a naming scheme that supports more variable-based include conditions, but currently Git only supports the exact keyword described above.

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

; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
	path = foo.inc

; include only if a remote with the given URL exists (note
; that such a URL may be provided later in a file or in a
; file read after this file is read, as seen in this example)
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
	path = foo.inc
[remote "origin"]
	url = https://example.com/git

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, white and default. The first color given is the foreground; the second is the background. All the basic colors except normal and default have a bright variant that can be specified by prefixing the color with bright, like brightred.

The color normal makes no change to the color. It is the same as an empty string, but can be used as the foreground color when specifying a background color alone (for example, "normal red").

The color default explicitly resets the color to the terminal default, for example to specify a cleared background. Although it varies between terminals, this is usually not the same as setting to "white black".

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, or 12-bit RGB values like #f1b, which is equivalent to the 24-bit color #ff11bb.

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).

The pseudo-attribute reset resets all colors and attributes before applying the specified coloring. For example, reset green will result in a green foreground and default background without any active attributes.

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.

If a path starts with %(prefix)/, the remainder is interpreted as a path relative to Git’s "runtime prefix", i.e. relative to the location where Git itself was installed. For example, %(prefix)/bin/ refers to the directory in which the Git executable itself lives. If Git was compiled without runtime prefix support, the compiled-in prefix will be substituted instead. In the unlikely event that a literal path needs to be specified that should not be expanded, it needs to be prefixed by ./, like so: ./%(prefix)/bin.

If prefixed with :(optional), the configuration variable is treated as if it does not exist, if the named path does not exist.

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.

add.ignoreErrors

add.ignore-errors (deprecated)

Tells git add to continue adding files when some files cannot be added due to indexing errors. Equivalent to the --ignore-errors option of git-add[1]. add.ignore-errors is deprecated, as it does not follow the usual naming convention for configuration variables.

advice.*

These variables control various optional help messages designed to aid new users. When left unconfigured, Git will give the message alongside instructions on how to squelch it. You can tell Git that you have understood the issue and no longer need a specific help message by setting the corresponding variable to false.

As they are intended to help human users, these messages are output to the standard error. When tools that run Git as a subprocess find them disruptive, they can set GIT_ADVICE=0 in the environment to squelch all advice messages.

addEmbeddedRepo: Shown when the user accidentally adds one git repo inside of another.
addEmptyPathspec: Shown when the user runs git add without providing the pathspec parameter.
addIgnoredFile: Shown when the user attempts to add an ignored file to the index.
amWorkDir: Shown when git-am[1] fails to apply a patch file, to tell the user the location of the file.
ambiguousFetchRefspec: Shown when a fetch refspec for multiple remotes maps to the same remote-tracking branch namespace and causes branch tracking set-up to fail.
checkoutAmbiguousRemoteBranchName: Shown when the argument to git-checkout[1] and git-switch[1] ambiguously resolves to a remote tracking branch on more than one remote in situations where an unambiguous argument would have otherwise caused a remote-tracking branch to be checked out. See the checkout.defaultRemote configuration variable for how to set a given remote to be used by default in some situations where this advice would be printed.
commitBeforeMerge: Shown when git-merge[1] refuses to merge to avoid overwriting local changes.
detachedHead: Shown when the user uses git-switch[1] or git-checkout[1] to move to the detached HEAD state, to tell the user how to create a local branch after the fact.
diverging: Shown when a fast-forward is not possible.
fetchShowForcedUpdates: Shown when git-fetch[1] takes a long time to calculate forced updates after ref updates, or to warn that the check is disabled.
forceDeleteBranch: Shown when the user tries to delete a not fully merged branch without the force option set.
ignoredHook: Shown when a hook is ignored because the hook is not set as executable.
implicitIdentity: Shown when the user’s information is guessed from the system username and domain name, to tell the user how to set their identity configuration.
mergeConflict: Shown when various commands stop because of conflicts.
nestedTag: Shown when a user attempts to recursively tag a tag object.
pushAlreadyExists: Shown when git-push[1] rejects an update that does not qualify for fast-forwarding (e.g., a tag.)
pushFetchFirst: Shown when git-push[1] rejects an update that tries to overwrite a remote ref that points at an object we do not have.
pushNeedsForce: Shown when git-push[1] rejects an update that tries to overwrite a remote ref that points at an object that is not a commit-ish, or make the remote ref point at an object that is not a commit-ish.
pushNonFFCurrent: Shown when git-push[1] fails due to a non-fast-forward update to the current branch.
pushNonFFMatching: Shown when the user ran git-push[1] and pushed "matching refs" explicitly (i.e. used :, or specified a refspec that isn’t the current branch) and it resulted in a non-fast-forward error.
pushRefNeedsUpdate: Shown when git-push[1] rejects a forced update of a branch when its remote-tracking ref has updates that we do not have locally.
pushUnqualifiedRefname: Shown when git-push[1] gives up trying to guess based on the source and destination refs what remote ref namespace the source belongs in, but where we can still suggest that the user push to either refs/heads/* or refs/tags/* based on the type of the source object.
pushUpdateRejected: Set this variable to false if you want to disable pushNonFFCurrent, pushNonFFMatching, pushAlreadyExists, pushFetchFirst, pushNeedsForce, and pushRefNeedsUpdate simultaneously.
rebaseTodoError: Shown when there is an error after editing the rebase todo list.
refSyntax: Shown when the user provides an illegal ref name, to tell the user about the ref syntax documentation.
resetNoRefresh: Shown when git-reset[1] takes more than 2 seconds to refresh the index after reset, to tell the user that they can use the --no-refresh option.
resolveConflict: Shown by various commands when conflicts prevent the operation from being performed.
rmHints: Shown on failure in the output of git-rm[1], to give directions on how to proceed from the current state.
sequencerInUse: Shown when a sequencer command is already in progress.
skippedCherryPicks: Shown when git-rebase[1] skips a commit that has already been cherry-picked onto the upstream branch.
sparseIndexExpanded: Shown when a sparse index is expanded to a full index, which is likely due to an unexpected set of files existing outside of the sparse-checkout.
statusAheadBehind: Shown when git-status[1] computes the ahead/behind counts for a local ref compared to its remote tracking ref, and that calculation takes longer than expected. Will not appear if status.aheadBehind is false or the option --no-ahead-behind is given.
statusHints: Show directions on how to proceed from the current state in the output of git-status[1], in the template shown when writing commit messages in git-commit[1], and in the help message shown by git-switch[1] or git-checkout[1] when switching branches.
statusUoption: Shown when git-status[1] takes more than 2 seconds to enumerate untracked files, to tell the user that they can use the -u option.
submoduleAlternateErrorStrategyDie: Shown when a submodule.alternateErrorStrategy option configured to "die" causes a fatal error.
submoduleMergeConflict: Advice shown when a non-trivial submodule merge conflict is encountered.
submodulesNotUpdated: Shown when a user runs a submodule command that fails because git submodule update --init was not run.
suggestDetachingHead: Shown when git-switch[1] refuses to detach HEAD without the explicit --detach option.
updateSparsePath: Shown when either git-add[1] or git-rm[1] is asked to update index entries outside the current sparse checkout.
waitingForEditor: Shown when Git is waiting for editor input. Relevant when e.g. the editor is not launched inside the terminal.
worktreeAddOrphan: Shown when the user tries to create a worktree from an invalid reference, to tell the user how to create a new unborn branch instead.

alias.*

Command aliases for the git[1] command wrapper - e.g. after defining alias.last = cat-file commit HEAD, the invocation git last is equivalent to git cat-file commit HEAD. To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored except for deprecated commands. Arguments are split by spaces, the usual shell quoting and escaping are supported. A quote pair or a backslash can be used to quote them.

Note that the first word of an alias does not necessarily have to be a command. It can be a command-line option that will be passed into the invocation of git. In particular, this is useful when used with -c to pass in one-time configurations or -p to force pagination. For example, loud-rebase = -c commit.verbose=true rebase can be defined such that running git loud-rebase would be equivalent to git -c commit.verbose=true rebase. Also, ps = -p status would be a helpful alias since git ps would paginate the output of git status where the original command does not.

If the alias expansion is prefixed with an exclamation point, it will be treated as a shell command. For example, defining alias.new = !gitk --all --not ORIG_HEAD, the invocation git new is equivalent to running the shell command gitk --all --not ORIG_HEAD. Note:

Shell commands will be executed from the top-level directory of a repository, which may not necessarily be the current directory.
GIT_PREFIX is set as returned by running git rev-parse --show-prefix from the original current directory. See git-rev-parse[1].
Shell command aliases always receive any extra arguments provided to the Git command-line as positional arguments.
- Care should be taken if your shell alias is a "one-liner" script with multiple commands (e.g. in a pipeline), references multiple arguments, or is otherwise not able to handle positional arguments added at the end. For example: alias.cmd = "!echo $1 | grep $2" called as git cmd 1 2 will be executed as echo $1 | grep $2 1 2, which is not what you want.
- A convenient way to deal with this is to write your script operations in an inline function that is then called with any arguments from the command-line. For example alias.cmd = "!c() { echo $1 | grep $2 ; }; c" will correctly execute the prior example.
- Setting GIT_TRACE=1 can help you debug the command being run for your alias.

am.keepcr

If true, git-am will call git-mailsplit for patches in mbox format with parameter --keep-cr. In this case git-mailsplit will not remove \r from lines ending with \r\n. Can be overridden by giving --no-keep-cr from the command line. See git-am[1], git-mailsplit[1].

am.threeWay

By default, git am will fail if the patch does not apply cleanly. When set to true, this setting tells git am to fall back on 3-way merge if the patch records the identity of blobs it is supposed to apply to and we have those blobs available locally (equivalent to giving the --3way option from the command line). Defaults to false. See git-am[1].

apply.ignoreWhitespace

When set to change, tells git apply to ignore changes in whitespace, in the same way as the --ignore-space-change option. When set to one of: no, none, never, false, it tells git apply to respect all whitespace differences. See git-apply[1].

apply.whitespace

Tells git apply how to handle whitespace, in the same way as the --whitespace option. See git-apply[1].

attr.tree

A reference to a tree in the repository from which to read attributes, instead of the .gitattributes file in the working tree. If the value does not resolve to a valid tree object, an empty tree is used instead. When the GIT_ATTR_SOURCE environment variable or --attr-source command line option are used, this configuration variable has no effect.

Note	The configuration options in `bitmapPseudoMerge.*` are considered EXPERIMENTAL and may be subject to change or be removed entirely in the future. For more information about the pseudo-merge bitmap feature, see the "Pseudo-merge bitmaps" section of gitpacking[7].

bitmapPseudoMerge.<name>.pattern

Regular expression used to match reference names. Commits pointed to by references matching this pattern (and meeting the below criteria, like bitmapPseudoMerge.<name>.sampleRate and bitmapPseudoMerge.<name>.threshold) will be considered for inclusion in a pseudo-merge bitmap.

Commits are grouped into pseudo-merge groups based on whether or not any reference(s) that point at a given commit match the pattern, which is an extended regular expression.

Within a pseudo-merge group, commits may be further grouped into sub-groups based on the capture groups in the pattern. These sub-groupings are formed from the regular expressions by concatenating any capture groups from the regular expression, with a - dash in between.

For example, if the pattern is refs/tags/, then all tags (provided they meet the below criteria) will be considered candidates for the same pseudo-merge group. However, if the pattern is instead refs/remotes/([0-9])+/tags/, then tags from different remotes will be grouped into separate pseudo-merge groups, based on the remote number.

bitmapPseudoMerge.<name>.decay

Determines the rate at which consecutive pseudo-merge bitmap groups decrease in size. Must be non-negative. This parameter can be thought of as k in the function f(n) = C * n^-k, where f(n) is the size of the `n`th group.

Setting the decay rate equal to 0 will cause all groups to be the same size. Setting the decay rate equal to 1 will cause the nth group to be 1/n the size of the initial group. Higher values of the decay rate cause consecutive groups to shrink at an increasing rate. The default is 1.

If all groups are the same size, it is possible that groups containing newer commits will be able to be used less often than earlier groups, since it is more likely that the references pointing at newer commits will be updated more often than a reference pointing at an old commit.

bitmapPseudoMerge.<name>.sampleRate

Determines the proportion of non-bitmapped commits (among reference tips) which are selected for inclusion in an unstable pseudo-merge bitmap. Must be between 0 and 1 (inclusive). The default is 1.

bitmapPseudoMerge.<name>.threshold

Determines the minimum age of non-bitmapped commits (among reference tips, as above) which are candidates for inclusion in an unstable pseudo-merge bitmap. The default is 1.week.ago.

bitmapPseudoMerge.<name>.maxMerges

Determines the maximum number of pseudo-merge commits among which commits may be distributed.

For pseudo-merge groups whose pattern does not contain any capture groups, this setting is applied for all commits matching the regular expression. For patterns that have one or more capture groups, this setting is applied for each distinct capture group.

For example, if your capture group is refs/tags/, then this setting will distribute all tags into a maximum of maxMerges pseudo-merge commits. However, if your capture group is, say, refs/remotes/([0-9]+)/tags/, then this setting will be applied to each remote’s set of tags individually.

Must be non-negative. The default value is 64.

bitmapPseudoMerge.<name>.stableThreshold

Determines the minimum age of commits (among reference tips, as above, however stable commits are still considered candidates even when they have been covered by a bitmap) which are candidates for a stable a pseudo-merge bitmap. The default is 1.month.ago.

Setting this threshold to a smaller value (e.g., 1.week.ago) will cause more stable groups to be generated (which impose a one-time generation cost) but those groups will likely become stale over time. Using a larger value incurs the opposite penalty (fewer stable groups which are more useful).

bitmapPseudoMerge.<name>.stableSize

Determines the size (in number of commits) of a stable psuedo-merge bitmap. The default is 512.

blame.blankBoundary

Show blank commit object name for boundary commits in git-blame[1]. This option defaults to false.

blame.coloring

This determines the coloring scheme to be applied to blame output. It can be repeatedLines, highlightRecent, or none which is the default.

blame.date

Specifies the format used to output dates in git-blame[1]. If unset the iso format is used. For supported values, see the discussion of the --date option at git-log[1].

blame.showEmail

Show the author email instead of author name in git-blame[1]. This option defaults to false.

blame.showRoot

Do not treat root commits as boundaries in git-blame[1]. This option defaults to false.

blame.ignoreRevsFile

Ignore revisions listed in the file, one unabbreviated object name per line, in git-blame[1]. Whitespace and comments beginning with # are ignored. This option may be repeated multiple times. Empty file names will reset the list of ignored revisions. This option will be handled before the command line option --ignore-revs-file.

blame.markUnblamableLines

Mark lines that were changed by an ignored revision that we could not attribute to another commit with a * in the output of git-blame[1].

blame.markIgnoredLines

Mark lines that were changed by an ignored revision that we attributed to another commit with a ? in the output of git-blame[1].

branch.autoSetupMerge

Tells git branch, git switch and git checkout to set up new branches so that git-pull[1] will appropriately merge from the starting point branch. Note that even if this option is not set, this behavior can be chosen per-branch using the --track and --no-track options. This option defaults to true. The valid settings are:

false: no automatic setup is done
true: automatic setup is done when the starting point is a remote-tracking branch
always: automatic setup is done when the starting point is either a local branch or remote-tracking branch
inherit: if the starting point has a tracking configuration, it is copied to the new branch
simple: automatic setup is done only when the starting point is a remote-tracking branch and the new branch has the same name as the remote branch.

branch.autoSetupRebase

When a new branch is created with git branch, git switch or git checkout that tracks another branch, this variable tells Git to set up pull to rebase instead of merge (see branch.<name>.rebase). The valid settings are:

never: rebase is never automatically set to true.
local: rebase is set to true for tracked branches of other local branches.
remote: rebase is set to true for tracked branches of remote-tracking branches.
always: rebase will be set to true for all tracking branches.

See branch.autoSetupMerge for details on how to set up a branch to track another branch. This option defaults to never.

branch.sort

This variable controls the sort ordering of branches when displayed by git-branch[1]. Without the --sort=<value> option provided, the value of this variable will be used as the default. See git-for-each-ref[1] field names for valid values.

branch.<name>.remote

When on branch <name>, it tells git fetch and git push which remote to fetch from or push to. The remote to push to may be overridden with remote.pushDefault (for all branches). The remote to push to, for the current branch, may be further overridden by branch.<name>.pushRemote. If no remote is configured, or if you are not on any branch and there is more than one remote defined in the repository, it defaults to origin for fetching and remote.pushDefault for pushing. Additionally, . (a period) is the current local repository (a dot-repository), see branch.<name>.merge's final note below.

branch.<name>.pushRemote

When on branch <name>, it overrides branch.<name>.remote for pushing. It also overrides remote.pushDefault for pushing from branch <name>. When you pull from one place (e.g. your upstream) and push to another place (e.g. your own publishing repository), you would want to set remote.pushDefault to specify the remote to push to for all branches, and use this option to override it for a specific branch.

branch.<name>.merge

Defines, together with branch.<name>.remote, the upstream branch for the given branch. It tells git fetch/git pull/git rebase which branch to merge and can also affect git push (see push.default). When in branch <name>, it tells git fetch the default refspec to be marked for merging in FETCH_HEAD. The value is handled like the remote part of a refspec, and must match a ref which is fetched from the remote given by branch.<name>.remote. The merge information is used by git pull (which first calls git fetch) to lookup the default branch for merging. Without this option, git pull defaults to merge the first refspec fetched. Specify multiple values to get an octopus merge. If you wish to setup git pull so that it merges into <name> from another branch in the local repository, you can point branch.<name>.merge to the desired branch, and use the relative path setting . (a period) for branch.<name>.remote.

branch.<name>.mergeOptions

Sets default options for merging into branch <name>. The syntax and supported options are the same as those of git-merge[1], but option values containing whitespace characters are currently not supported.

branch.<name>.rebase

When true, rebase the branch <name> on top of the fetched branch, instead of merging the default branch from the default remote when git pull is run. See pull.rebase for doing this in a non branch-specific manner.

When merges (or just m), pass the --rebase-merges option to git rebase so that the local merge commits are included in the rebase (see git-rebase[1] for details).

When the value is interactive (or just i), the rebase is run in interactive mode.

NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase[1] for details).

branch.<name>.description

Branch description, can be edited with git branch --edit-description. Branch description is automatically added to the format-patch cover letter or request-pull summary.

browser.<tool>.cmd

Specify the command to invoke the specified browser. The specified command is evaluated in shell with the URLs passed as arguments. (See git-web--browse[1].)

browser.<tool>.path

Override the path for the given tool that may be used to browse HTML help (see -w option in git-help[1]) or a working repository in gitweb (see git-instaweb[1]).

bundle.*

The bundle.* keys may appear in a bundle list file found via the git clone --bundle-uri option. These keys currently have no effect if placed in a repository config file, though this will change in the future. See the bundle URI design document for more details.

bundle.version

This integer value advertises the version of the bundle list format used by the bundle list. Currently, the only accepted value is 1.

bundle.mode

This string value should be either all or any. This value describes whether all of the advertised bundles are required to unbundle a complete understanding of the bundled information (all) or if any one of the listed bundle URIs is sufficient (any).

bundle.heuristic

If this string-valued key exists, then the bundle list is designed to work well with incremental git fetch commands. The heuristic signals that there are additional keys available for each bundle that help determine which subset of bundles the client should download. The only value currently understood is creationToken.

bundle.<id>.*

The bundle.<id>.* keys are used to describe a single item in the bundle list, grouped under <id> for identification purposes.

bundle.<id>.uri

This string value defines the URI by which Git can reach the contents of this <id>. This URI may be a bundle file or another bundle list.

checkout.defaultRemote

When you run git checkout <something> or git switch <something> and only have one remote, it may implicitly fall back on checking out and tracking e.g. origin/<something>. This stops working as soon as you have more than one remote with a <something> reference. This setting allows for setting the name of a preferred remote that should always win when it comes to disambiguation. The typical use-case is to set this to origin.

Currently this is used by git-switch[1] and git-checkout[1] when git checkout <something> or git switch <something> will checkout the <something> branch on another remote, and by git-worktree[1] when git worktree add refers to a remote branch. This setting might be used for other checkout-like commands or functionality in the future.

checkout.guess

Provides the default value for the --guess or --no-guess option in git checkout and git switch. See git-switch[1] and git-checkout[1].

checkout.workers

The number of parallel workers to use when updating the working tree. The default is one, i.e. sequential execution. If set to a value less than one, Git will use as many workers as the number of logical cores available. This setting and checkout.thresholdForParallelism affect all commands that perform checkout. E.g. checkout, clone, reset, sparse-checkout, etc.

Note

Parallel checkout usually delivers better performance for repositories located on SSDs or over NFS. For repositories on spinning disks and/or machines with a small number of cores, the default sequential checkout often performs better. The size and compression level of a repository might also influence how well the parallel version performs.

checkout.thresholdForParallelism

When running parallel checkout with a small number of files, the cost of subprocess spawning and inter-process communication might outweigh the parallelization gains. This setting allows you to define the minimum number of files for which parallel checkout should be attempted. The default is 100.

clean.requireForce

A boolean to make git-clean refuse to delete files unless -f is given. Defaults to true.

clone.defaultRemoteName

The name of the remote to create when cloning a repository. Defaults to origin. It can be overridden by passing the --origin command-line option to git-clone[1].

clone.rejectShallow

Reject cloning a repository if it is a shallow one; this can be overridden by passing the --reject-shallow option on the command line. See git-clone[1].

clone.filterSubmodules

If a partial clone filter is provided (see --filter in git-rev-list[1]) and --recurse-submodules is used, also apply the filter to submodules.

color.advice

A boolean to enable/disable color in hints (e.g. when a push failed, see advice.* for a list). May be set to always, false (or never) or auto (or true), in which case colors are used only when the error output goes to a terminal. If unset, then the value of color.ui is used (auto by default).

color.advice.hint

Use customized color for hints.

color.blame.highlightRecent

Specify the line annotation color for git blame --color-by-age depending upon the age of the line.

This setting should be set to a comma-separated list of color and date settings, starting and ending with a color, the dates should be set from oldest to newest. The metadata will be colored with the specified colors if the line was introduced before the given timestamp, overwriting older timestamped colors.

Instead of an absolute timestamp relative timestamps work as well, e.g. 2.weeks.ago is valid to address anything older than 2 weeks.

It defaults to blue,12 month ago,white,1 month ago,red, which colors everything older than one year blue, recent changes between one month and one year old are kept white, and lines introduced within the last month are colored red.

color.blame.repeatedLines

Use the specified color to colorize line annotations for git blame --color-lines, if they come from the same commit as the preceding line. Defaults to cyan.

color.branch

A boolean to enable/disable color in the output of git-branch[1]. May be set to always, false (or never) or auto (or true), in which case colors are used only when the output is to a terminal. If unset, then the value of color.ui is used (auto by default).

color.branch.<slot>

Use customized color for branch coloration. <slot> is one of current (the current branch), local (a local branch), remote (a remote-tracking branch in refs/remotes/), upstream (upstream tracking branch), plain (other refs).

color.diff

Whether to use ANSI escape sequences to add color to patches. If this is set to always, git-diff[1], git-log[1], and git-show[1] will use color for all patches. If it is set to true or auto, those commands will only use color when output is to the terminal. If unset, then the value of color.ui is used (auto by default).

This does not affect git-format-patch[1] or the git-diff-* plumbing commands. Can be overridden on the command line with the --color[=<when>] option.

color.diff.<slot>

Use customized color for diff colorization. <slot> specifies which part of the patch to use the specified color, and is one of context (context text - plain is a historical synonym), meta (metainformation), frag (hunk header), func (function in hunk header), old (removed lines), new (added lines), commit (commit headers), whitespace (highlighting whitespace errors), oldMoved (deleted lines), newMoved (added lines), oldMovedDimmed, oldMovedAlternative, oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative newMovedAlternativeDimmed (See the <mode> setting of --color-moved in git-diff[1] for details), contextDimmed, oldDimmed, newDimmed, contextBold, oldBold, and newBold (see git-range-diff[1] for details).

color.decorate.<slot>

Use customized color for git log --decorate output. <slot> is one of branch, remoteBranch, tag, stash or HEAD for local branches, remote-tracking branches, tags, stash and HEAD, respectively and grafted for grafted commits.

color.grep

When set to always, always highlight matches. When false (or never), never. When set to true or auto, use color only when the output is written to the terminal. If unset, then the value of color.ui is used (auto by default).

color.grep.<slot>

Use customized color for grep colorization. <slot> specifies which part of the line to use the specified color, and is one of

context: non-matching text in context lines (when using -A, -B, or -C)
filename: filename prefix (when not using -h)
function: function name lines (when using -p)
lineNumber: line number prefix (when using -n)
column: column number prefix (when using --column)
match: matching text (same as setting matchContext and matchSelected)
matchContext: matching text in context lines
matchSelected: matching text in selected lines. Also, used to customize the following git-log[1] subcommands: --grep, --author, and --committer.
selected: non-matching text in selected lines. Also, used to customize the following git-log[1] subcommands: --grep, --author and --committer.
separator: separators between fields on a line (:, -, and =) and between hunks (--)

color.interactive

When set to always, always use colors for interactive prompts and displays (such as those used by "git-add --interactive" and "git-clean --interactive"). When false (or never), never. When set to true or auto, use colors only when the output is to the terminal. If unset, then the value of color.ui is used (auto by default).

color.interactive.<slot>

Use customized color for git add --interactive and git clean --interactive output. <slot> may be prompt, header, help or error, for four distinct types of normal output from interactive commands.

color.pager

A boolean to specify whether auto color modes should colorize output going to the pager. Defaults to true; set this to false if your pager does not understand ANSI color codes.

color.push

A boolean to enable/disable color in push errors. May be set to always, false (or never) or auto (or true), in which case colors are used only when the error output goes to a terminal. If unset, then the value of color.ui is used (auto by default).

color.push.error

Use customized color for push errors.

color.remote

If set, keywords at the start of the line are highlighted. The keywords are "error", "warning", "hint" and "success", and are matched case-insensitively. May be set to always, false (or never) or auto (or true). If unset, then the value of color.ui is used (auto by default).

color.remote.<slot>

Use customized color for each remote keyword. <slot> may be hint, warning, success or error which match the corresponding keyword.

color.showBranch

A boolean to enable/disable color in the output of git-show-branch[1]. May be set to always, false (or never) or auto (or true), in which case colors are used only when the output is to a terminal. If unset, then the value of color.ui is used (auto by default).

color.status

A boolean to enable/disable color in the output of git-status[1]. May be set to always, false (or never) or auto (or true), in which case colors are used only when the output is to a terminal. If unset, then the value of color.ui is used (auto by default).

color.status.<slot>

Use customized color for status colorization. <slot> is one of header (the header text of the status message), added or updated (files which are added but not committed), changed (files which are changed but not added in the index), untracked (files which are not tracked by Git), branch (the current branch), nobranch (the color the no branch warning is shown in, defaulting to red), localBranch or remoteBranch (the local and remote branch names, respectively, when branch and tracking information is displayed in the status short-format), or unmerged (files which have unmerged changes).

color.transport

A boolean to enable/disable color when pushes are rejected. May be set to always, false (or never) or auto (or true), in which case colors are used only when the error output goes to a terminal. If unset, then the value of color.ui is used (auto by default).

color.transport.rejected

Use customized color when a push was rejected.

color.ui

This variable determines the default value for variables such as color.diff and color.grep that control the use of color per command family. Its scope will expand as more commands learn configuration to set a default for the --color option. Set it to false or never if you prefer Git commands not to use color unless enabled explicitly with some other configuration or the --color option. Set it to always if you want all output not intended for machine consumption to use color, to true or auto (this is the default since Git 1.8.4) if you want such output to use color when written to the terminal.

column.ui

Specify whether supported commands should output in columns. This variable consists of a list of tokens separated by spaces or commas:

These options control when the feature should be enabled (defaults to never):

always: always show in columns
never: never show in columns
auto: show in columns if the output is to the terminal

These options control layout (defaults to column). Setting any of these implies always if none of always, never, or auto are specified.

column: fill columns before rows
row: fill rows before columns
plain: show in one column

Finally, these options can be combined with a layout option (defaults to nodense):

dense: make unequal size columns to utilize more space
nodense: make equal size columns

column.branch

Specify whether to output branch listing in git branch in columns. See column.ui for details.

column.clean

Specify the layout when listing items in git clean -i, which always shows files and directories in columns. See column.ui for details.

column.status

Specify whether to output untracked files in git status in columns. See column.ui for details.

column.tag

Specify whether to output tag listings in git tag in columns. See column.ui for details.

commit.cleanup: This setting overrides the default of the --cleanup option in git commit. See git-commit[1] for details. Changing the default can be useful when you always want to keep lines that begin with the comment character (core.commentChar, default #) in your log message, in which case you would do git config commit.cleanup whitespace (note that you will have to remove the help lines that begin with the comment character in the commit log template yourself, if you do this).
commit.gpgSign: A boolean to specify whether all commits should be GPG signed. Use of this option when doing operations such as rebase can result in a large number of commits being signed. It may be convenient to use an agent to avoid typing your GPG passphrase several times.
commit.status: A boolean to enable/disable inclusion of status information in the commit message template when using an editor to prepare the commit message. Defaults to true.
commit.template: Specify the pathname of a file to use as the template for new commit messages.
commit.verbose: A boolean or int to specify the level of verbosity with git commit. See git-commit[1] for details.

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands

NAME

SYNOPSIS

DESCRIPTION

COMMANDS

OPTIONS

DEPRECATED MODES

CONFIGURATION

FILES

SCOPES

Protected configuration

ENVIRONMENT

EXAMPLES

CONFIGURATION FILE

Syntax

Includes

Conditional includes

Example

Values

Variables