git-config(1)

NAME#

git-config - Get and set repository or global options

SYNOPSIS#

git config list\n [<file-option>] [<display-option>] [--includes]
\ngit config get\n [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<value>] [--fixed-value] [--default=<default>] <name>
\ngit config set\n [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value>
\ngit config unset\n [<file-option>] [--all] [--value=<value>] [--fixed-value] <name>
\ngit config rename-section\n [<file-option>] <old-name> <new-name>
\ngit config remove-section\n [<file-option>] <name>
\ngit config edit\n [<file-option>]
\ngit config\n [<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, a 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 the section called “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 the section called “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:

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

get

set

unset

rename-section

remove-section

edit

OPTIONS#

--replace-all

--append

--comment <message>

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

--regexp

--url=<URL>

--global

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

See also the section called “FILES”.

--system

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

See also the section called “FILES”.

--local

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

See also the section called “FILES”.

--worktree

-f <config-file>, --file <config-file>

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

See also the section called “FILES”.

--blob <blob>

--fixed-value

--type <type>

Valid <type>'s include:

--bool, --int, --bool-or-int, --path, --expiry-date

--no-type

-z, --null

--name-only

--show-origin

--show-scope

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

--[no-]includes

--default <value>

DEPRECATED MODES#

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

git config <name>

git config <name> <value> [<value-pattern>]

-l, --list

--get <name> [<value-pattern>]

--get-all <name> [<value-pattern>]

--get-regexp <name-regexp>

--get-urlmatch <name> <URL>

--get-color <name> [<default>]

--add <name> <value>

--unset <name> [<value-pattern>]

--unset-all <name> [<value-pattern>]

--rename-section <old-name> <new-name>

--remove-section <name>

-e, --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

$XDG_CONFIG_HOME/git/config, ~/.gitconfig

These are also called "global" configuration files. If both files exist, both files are read in the order given above.

$GIT_DIR/config

$GIT_DIR/config.worktree

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 configwill 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 the section called “OPTIONS” above.

SCOPES#

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

system

global

~/.gitconfig

local

worktree

command

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 the section called “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

GIT_CONFIG_NOSYSTEM

See also the section called “FILES”.

GIT_CONFIG_COUNT, GIT_CONFIG_KEY_<n>, GIT_CONFIG_VALUE_<n>

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

EXAMPLES#

Given a .git/config like this:

#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
\n
        ; Don't trust file modes
\n
        filemode = false
; Our diff algorithm
[diff]
\n
        external = /usr/local/bin/diff-wrapper
\n
        renames = true
; Proxy settings
[core]
\n
        gitproxy=proxy-command for kernel.org
\n
        gitproxy=default-proxy ; for all the rest
; HTTP
[http]
\n
        sslVerify
[http "https://weak.example.com"]
\n
        sslVerify = false
\n
        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:

\n
        [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 .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:

gitdir/i

onbranch

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:

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:

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.

Example#

# Core variables
[core]
\n
        ; Don't trust file modes
\n
        filemode = false
# Our diff algorithm
[diff]
\n
        external = /usr/local/bin/diff-wrapper
\n
        renames = true
[branch "devel"]
\n
        remote = origin
\n
        merge = refs/heads/devel
# Proxy settings
[core]
\n
        gitProxy="ssh" for "kernel.org"
\n
        gitProxy=default-proxy ; for the rest
[include]
\n
        path = /path/to/foo.inc ; include by absolute path
\n
        path = foo.inc ; find "foo.inc" relative to the current file
\n
        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"]
\n
        path = /path/to/foo.inc
; include for all repositories inside /path/to/group
[includeIf "gitdir:/path/to/group/"]
\n
        path = /path/to/foo.inc
; include for all repositories inside $HOME/to/group
[includeIf "gitdir:~/to/group/"]
\n
        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/"]
\n
        path = foo.inc
; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
\n
        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/**"]
\n
        path = foo.inc
[remote "origin"]
\n
        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

true

false

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

color

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

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.

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)

advice.*

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

addEmptyPathspec

addIgnoredFile

amWorkDir

ambiguousFetchRefspec

checkoutAmbiguousRemoteBranchName

commitBeforeMerge

detachedHead

diverging

fetchShowForcedUpdates

forceDeleteBranch

ignoredHook

implicitIdentity

mergeConflict

nestedTag

pushAlreadyExists

pushFetchFirst

pushNeedsForce

pushNonFFCurrent

pushNonFFMatching

pushRefNeedsUpdate

pushUnqualifiedRefname

pushUpdateRejected

rebaseTodoError

refSyntax

resetNoRefresh

resolveConflict

rmHints

sequencerInUse

skippedCherryPicks

sparseIndexExpanded

statusAheadBehind

statusHints

statusUoption

submoduleAlternateErrorStrategyDie

submoduleMergeConflict

submodulesNotUpdated

suggestDetachingHead

updateSparsePath

waitingForEditor

worktreeAddOrphan

alias.*

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:

am.keepcr

am.threeWay

apply.ignoreWhitespace

apply.whitespace

attr.tree

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

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

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 n`th 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

bitmapPseudoMerge.<name>.threshold

bitmapPseudoMerge.<name>.maxMerges

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

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

blame.blankBoundary

blame.coloring

blame.date

blame.showEmail

blame.showRoot

blame.ignoreRevsFile

blame.markUnblamableLines

blame.markIgnoredLines

branch.autoSetupMerge

branch.autoSetupRebase

branch.sort

branch.<name>.remote

branch.<name>.pushRemote

branch.<name>.merge

branch.<name>.mergeOptions

branch.<name>.rebase

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

browser.<tool>.cmd

browser.<tool>.path

bundle.*

bundle.version

bundle.mode

bundle.heuristic

bundle.<id>.*

bundle.<id>.uri

checkout.defaultRemote

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

checkout.workers

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

clean.requireForce

clone.defaultRemoteName

clone.rejectShallow

clone.filterSubmodules

color.advice

color.advice.hint

color.blame.highlightRecent

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

color.branch

color.branch.<slot>

color.diff

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>

color.decorate.<slot>

color.grep

color.grep.<slot>

context

filename

function

lineNumber

column

match

matchContext

matchSelected

selected

separator

color.interactive

color.interactive.<slot>

color.pager

color.push

color.push.error

color.remote

color.remote.<slot>

color.showBranch

color.status

color.status.<slot>

color.transport

color.transport.rejected

color.ui

column.ui

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

always

never

auto

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

column

row

plain

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

dense

nodense

column.branch

column.clean

column.status

column.tag

commit.cleanup

commit.gpgSign

commit.status

commit.template

commit.verbose

commitGraph.generationVersion

commitGraph.maxNewFilters

commitGraph.readChangedPaths

commitGraph.changedPathsVersion

Defaults to -1.

If -1, Git will use the version of the changed-path Bloom filters in the repository, defaulting to 1 if there are none.

If 0, Git will not read any Bloom filters, and will write version 1 Bloom filters when instructed to write.

If 1, Git will only read version 1 Bloom filters, and will write version 1 Bloom filters.

If 2, Git will only read version 2 Bloom filters, and will write version 2 Bloom filters.

See git-commit-graph(1) for more information.

completion.commands

core.fileMode

Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out a non-executable file with executable bit on. git-clone(1) or git-init(1) probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index(1).

The default is true (when core.filemode is not specified in the config file).

core.hideDotFiles

core.ignoreCase

The default is false, except git-clone(1) or git-init(1) will probe and set core.ignoreCase true if appropriate when the repository is created.

Git relies on the proper configuration of this variable for your operating and file system. Modifying this value may result in unexpected behavior.

core.precomposeUnicode

core.protectHFS

core.protectNTFS

core.fsmonitor

Like hook-based file system monitors, the built-in file system monitor can speed up Git commands that need to refresh the Git index (e.g. git status) in a working directory with many files. The built-in monitor eliminates the need to install and maintain an external third-party tool.

The built-in file system monitor is currently available only on a limited set of supported platforms. Currently, this includes Windows and MacOS.

Otherwise, this variable contains the pathname of the "fsmonitor"
hook command.

This hook command is used to identify all files that may have changed since the requested date/time. This information is used to speed up git by avoiding unnecessary scanning of files that have not changed.

See the "fsmonitor-watchman" section of githooks(5).

Note that if you concurrently use multiple versions of Git, such as one version on the command line and another version in an IDE tool, that the definition of core.fsmonitor was extended to allow boolean values in addition to hook pathnames. Git versions 2.35.1 and prior will not understand the boolean values and will consider the "true" or "false" values as hook pathnames to be invoked. Git versions 2.26 thru 2.35.1 default to hook protocol V2 and will fall back to no fsmonitor (full scan). Git versions prior to 2.26 default to hook protocol V1 and will silently assume there were no changes to report (no scan), so status commands may report incomplete results. For this reason, it is best to upgrade all of your Git versions before using the built-in file system monitor.

core.fsmonitorHookVersion

There are currently versions 1 and 2. When this is not set, version 2 will be tried first and if it fails then version 1 will be tried. Version 1 uses a timestamp as input to determine which files have changes since that time but some monitors like Watchman have race conditions when used with a timestamp. Version 2 uses an opaque string so that the monitor can return something that can be used to determine what files have changed without race conditions.

core.trustctime

core.splitIndex

core.untrackedCache

core.checkStat

There are implementations of Git that do not leave usable values in some fields (e.g. JGit); by excluding these fields from the comparison, the minimal mode may help interoperability when the same repository is used by these other systems at the same time.

core.quotePath

core.eol

core.safecrlf

CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.

If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell Git that this file is binary and Git will handle the file appropriately.

Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data.

Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of core.eol and core.autocrlf, but only for the current one. For example, a text file with LF would be accepted with core.eol=lf and could later be checked out with core.eol=crlf, in which case the resulting file would contain CRLF, although the original file contained LF. However, in both work trees the line endings would be consistent, that is either all LF or all CRLF, but never mixed. A file with mixed line endings would be reported by the core.safecrlf mechanism.

core.autocrlf

core.checkRoundtripEncoding

core.symlinks

The default is true, except git-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created.

core.gitProxy

Can be overridden by the GIT_PROXY_COMMAND environment variable (which always applies universally, without the special "for" handling).

The special string none can be used as the proxy command to specify that no proxy be used for a given domain pattern. This is useful for excluding servers inside a firewall from proxy use, while defaulting to a common proxy for external domains.

core.sshCommand

core.ignoreStat

When files are modified outside of Git, the user will need to stage the modified files explicitly (e.g. see Examples section in git-update-index(1)). Git will not normally detect changes to those files.

This is useful on systems where lstat() calls are very slow, such as CIFS/Microsoft Windows.

False by default.

core.preferSymlinkRefs

core.alternateRefsCommand

Note that you cannot generally put git for-each-ref directly into the config value, as it does not take a repository path as an argument (but you can wrap the command above in a shell script).

core.alternateRefsPrefixes

core.bare

This setting is automatically guessed by git-clone(1) or git-init(1) when the repository was created. By default a repository that ends in "/.git" is assumed to be not bare (bare = false), while all other repositories are assumed to be bare (bare = true).

core.worktree

Note that this variable is honored even when set in a configuration file in a ".git" subdirectory of a directory and its value differs from the latter directory (e.g. "/path/to/.git/config" has core.worktree set to "/different/path"), which is most likely a misconfiguration. Running Git commands in the "/path/to" directory will still use "/different/path" as the root of the work tree and can cause confusion unless you know what you are doing (e.g. you are creating a read-only snapshot of the same index to a location different from the repository’s usual working tree).

core.logAllRefUpdates

This information can be used to determine what commit was the tip of a branch "2 days ago".

This value is true by default in a repository that has a working directory associated with it, and false by default in a bare repository.

core.repositoryFormatVersion

core.sharedRepository

core.warnAmbiguousRefs

core.compression

core.looseCompression

core.packedGitWindowSize

Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should be reasonable for all users/operating systems. You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

core.packedGitLimit

Default is 256 MiB on 32 bit platforms and 32 TiB (effectively unlimited) on 64 bit platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

core.deltaBaseCacheLimit

Default is 96 MiB on all platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

core.bigFileThreshold

Files above the configured limit will be:

The default limit is primarily set with this use-case in mind. With it, most projects will have their source code and other text files delta compressed, but not larger binary media files.

Storing large files without delta compression avoids excessive memory usage, at the slight expense of increased disk usage.

core.excludesFile

core.askPass

core.attributesFile

core.hooksPath

The path can be either absolute or relative. A relative path is taken as relative to the directory where the hooks are run (see the "DESCRIPTION" section of githooks(5)).

This configuration variable is useful in cases where you’d like to centrally configure your Git hooks instead of configuring them on a per-repository basis, or as a more flexible and centralized alternative to having an init.templateDir where you’ve changed default hooks.

core.editor

core.commentChar, core.commentString

If set to "auto", git-commit would select a character that is not the beginning character of any line in existing commit messages.

Note that these two variables are aliases of each other, and in modern versions of Git you are free to use a string (e.g., // or ⁑⁕⁑) with commentChar. Versions of Git prior to v2.45.0 will ignore commentString but will reject a value of commentChar that consists of more than a single ASCII byte. If you plan to use your config with older and newer versions of Git, you may want to specify both:

[core]
# single character for older versions
commentChar = "#"
# string for newer versions (which will override commentChar
# because it comes later in the file)
commentString = "//"

core.filesRefLockTimeout

core.packedRefsTimeout

core.pager

When the LESS environment variable is unset, Git sets it to FRX (if LESS environment variable is set, Git does not change it at all). If you want to selectively override Git’s default setting for LESS, you can set core.pager to e.g. less -S. This will be passed to the shell by Git, which will translate the final command to LESS=FRX less -S. The environment does not set the S option but the command line does, instructing less to truncate long lines. Similarly, setting core.pager to less -+F will deactivate the F option specified by the environment from the command-line, deactivating the "quit if one screen" behavior of less. One can specifically activate some flags for particular commands: for example, setting pager.blame to less -S enables line truncation only for git blame.

Likewise, when the LV environment variable is unset, Git sets it to -c. You can override this setting by exporting LV with another value or setting core.pager to lv +c.

core.whitespace

core.fsync

When this configuration is encountered, the set of components starts with the platform default value, disabled components are removed, and additional components are added. none resets the state so that the platform default is ignored.

The empty string resets the fsync configuration to the platform default. The default on most platforms is equivalent to core.fsync=committed,-loose-object, which has good performance, but risks losing recent work in the event of an unclean system shutdown.

core.fsyncMethod

Currently batch mode only applies to loose-object files. Other repository data is made durable as if fsync was specified. This mode is expected to be as safe as fsync on macOS for repos stored on HFS+ or APFS filesystems and on Windows for repos stored on NTFS or ReFS filesystems.

core.fsyncObjectFiles

This setting affects data added to the Git repository in loose-object form. When set to true, Git will issue an fsync or similar system call to flush caches so that loose-objects remain consistent in the face of a unclean system shutdown.

core.preloadIndex

This can speed up operations like git diff and git status especially on filesystems like NFS that have weak caching semantics and thus relatively high IO latencies. When enabled, Git will do the index comparison to the filesystem data in parallel, allowing overlapping IO’s. Defaults to true.

core.unsetenvvars

core.restrictinheritedhandles

core.createObject

On some file system/operating system combinations, this is unreliable. Set this config setting to rename there; however, this will remove the check that makes sure that existing object files will not get overwritten.

core.notesRef

This setting defaults to "refs/notes/commits", and it can be overridden by the GIT_NOTES_REF environment variable. See git-notes(1).

core.commitGraph

core.useReplaceRefs

core.multiPackIndex

core.sparseCheckout

core.sparseCheckoutCone

core.abbrev

core.maxTreeDepth

credential.helper

Note that multiple helpers may be defined. See gitcredentials(7) for details and examples.

credential.interactive

credential.useHttpPath

credential.sanitizePrompt

credential.protectProtocol

credential.username

credential.<url>.*

credentialCache.ignoreSIGHUP

credentialStore.lockTimeoutMS

diff.autoRefreshIndex

diff.dirstat

changes

lines

files

cumulative

<limit>

Example: The following will count changed files, while ignoring directories with less than 10% of the total amount of changed files, and accumulating child directory counts in the parent directories: files,10,cumulative.

diff.statNameWidth

diff.statGraphWidth

diff.context

diff.interHunkContext

diff.external

diff.trustExitCode

diff.ignoreSubmodules

diff.mnemonicPrefix

git diff

git diff HEAD

git diff --cached

git diff HEAD:file1 file2

git diff --no-index a b

diff.noPrefix

diff.srcPrefix

diff.dstPrefix

diff.relative

diff.orderFile

diff.renameLimit

diff.renames

diff.suppressBlankEmpty

diff.submodule

diff.wordRegex

diff.<driver>.command

diff.<driver>.trustExitCode

diff.<driver>.xfuncname

diff.<driver>.binary

diff.<driver>.textconv

diff.<driver>.wordRegex

diff.<driver>.cachetextconv

araxis

bc

bc3

bc4

codecompare

deltawalker

diffmerge

diffuse

ecmerge

emerge

examdiff

guiffy

gvimdiff

kdiff3

kompare

meld

nvimdiff

opendiff

p4merge

smerge

tkdiff

vimdiff

vscode

winmerge

xxdiff

diff.indentHeuristic

diff.algorithm

default, myers

minimal

patience

histogram

diff.wsErrorHighlight

diff.colorMoved

diff.colorMovedWS

diff.tool

diff.guitool

difftool.<tool>.cmd

See the --tool=<tool> option in git-difftool(1) for more details.

difftool.<tool>.path

difftool.trustExitCode

See the --trust-exit-code option in git-difftool(1) for more details.

difftool.prompt

difftool.guiDefault

extensions.objectFormat

Note that this setting should only be set by git-init(1) or git-clone(1). Trying to change it after initialization will not work and will produce hard-to-diagnose issues.

extensions.compatObjectFormat

extensions.refStorage

It is an error to specify this key unless core.repositoryFormatVersion is 1.

Note that this setting should only be set by git-init(1) or git-clone(1). Trying to change it after initialization will not work and will produce hard-to-diagnose issues.

extensions.worktreeConfig

When enabling extensions.worktreeConfig, you must be careful to move certain values from the common config file to the main working tree’s config.worktree file, if present:

It may also be beneficial to adjust the locations of core.sparseCheckout and core.sparseCheckoutCone depending on your desire for customizable sparse-checkout settings for each worktree. By default, the git sparse-checkout builtin enables extensions.worktreeConfig, assigns these config values on a per-worktree basis, and uses the $GIT_DIR/info/sparse-checkout file to specify the sparsity for each worktree independently. See git-sparse-checkout(1) for more details.

For historical reasons, extensions.worktreeConfig is respected regardless of the core.repositoryFormatVersion setting.

fastimport.unpackLimit

feature.*

feature.experimental

feature.manyFiles

fetch.recurseSubmodules

fetch.fsckObjects

fetch.fsck.<msg-id>

fetch.fsck.skipList

fetch.unpackLimit

fetch.prune

fetch.pruneTags

fetch.all

fetch.output

fetch.negotiationAlgorithm

See also the --negotiate-only and --negotiation-tip options to git-fetch(1).

fetch.showForcedUpdates

fetch.parallel

A value of 0 will give some reasonable default. If unset, it defaults to 1.

For submodules, this setting can be overridden using the submodule.fetchJobs config setting.

fetch.writeCommitGraph

fetch.bundleURI

If you modify this value and your repository has a fetch.bundleCreationToken value, then remove that fetch.bundleCreationToken value before fetching from the new bundle URI.

fetch.bundleCreationToken

The creation token values are chosen by the provider serving the specific bundle URI. If you modify the URI at fetch.bundleURI, then be sure to remove the value for the fetch.bundleCreationToken value before fetching.

filter.<driver>.clean

filter.<driver>.smudge

format.attach

format.from

format.forceInBodyFrom

format.numbered

format.headers

format.to, format.cc

format.subjectPrefix

format.coverFromDescription

format.signature

format.signatureFile

format.suffix

format.encodeEmailHeaders

format.pretty

format.thread

format.signOff

format.coverLetter

format.outputDirectory

format.filenameMaxLength

format.useAutoBase

format.notes

If one wishes to use the ref refs/notes/true, please use that literal instead.

This configuration can be specified multiple times in order to allow multiple notes refs to be included. In that case, it will behave similarly to multiple --[no-]notes[=] options passed in. That is, a value of true will show the default notes, a value of <ref> will also show notes from that notes ref and a value of false will negate previous configurations and not show notes.

For example,

[format]
\n
        notes = true
\n
        notes = foo
\n
        notes = false
\n
        notes = bar

will only show notes from refs/notes/bar.

format.mboxrd

format.noprefix

fsck.<msg-id>

Setting fsck.<msg-id> will be picked up by git-fsck(1), but to accept pushes of such data set receive.fsck.<msg-id> instead, or to clone or fetch it set fetch.fsck.<msg-id>.

The rest of the documentation discusses fsck.* for brevity, but the same applies for the corresponding receive.fsck.* and fetch.fsck.*. variables.

Unlike variables like color.ui and core.editor, the receive.fsck.<msg-id> and fetch.fsck.<msg-id> variables will not fall back on the fsck.<msg-id> configuration if they aren’t set. To uniformly configure the same fsck settings in different circumstances, all three of them must be set to the same values.

When fsck.<msg-id> is set, errors can be switched to warnings and vice versa by configuring the fsck.<msg-id> setting where the <msg-id> is the fsck message ID and the value is one of error, warn or ignore. For convenience, fsck prefixes the error/warning with the message ID, e.g. "missingEmail: invalid author/committer line - missing email" means that setting fsck.missingEmail = ignore will hide that issue.

In general, it is better to enumerate existing objects with problems with fsck.skipList, instead of listing the kind of breakages these problematic objects share to be ignored, as doing the latter will allow new instances of the same breakages go unnoticed.

Setting an unknown fsck.<msg-id> value will cause fsck to die, but doing the same for receive.fsck.<msg-id> and fetch.fsck.<msg-id> will only cause git to warn.

See the Fsck Messages section of git-fsck(1) for supported values of <msg-id>.

fsck.skipList

This feature is useful when an established project should be accepted despite early commits containing errors that can be safely ignored, such as invalid committer email addresses. Note: corrupt objects cannot be skipped with this setting.

Like fsck.<msg-id> this variable has corresponding receive.fsck.skipList and fetch.fsck.skipList variants.

Unlike variables like color.ui and core.editor the receive.fsck.skipList and fetch.fsck.skipList variables will not fall back on the fsck.skipList configuration if they aren’t set. To uniformly configure the same fsck settings in different circumstances, all three of them must be set to the same values.

Older versions of Git (before 2.20) documented that the object names list should be sorted. This was never a requirement; the object names could appear in any order, but when reading the list we tracked whether the list was sorted for the purposes of an internal binary search implementation, which could save itself some work with an already sorted list. Unless you had a humongous list there was no reason to go out of your way to pre-sort the list. After Git version 2.20 a hash implementation is used instead, so there’s now no reason to pre-sort the list.

fsmonitor.allowRemote

fsmonitor.socketDir

gc.aggressiveDepth

See the documentation for the --depth option in git-repack(1) for more details.

gc.aggressiveWindow

See the documentation for the --window option in git-repack(1) for more details.

gc.auto

Setting this to 0 disables not only automatic packing based on the number of loose objects, but also any other heuristic git gc --auto will otherwise use to determine if there’s work to do, such as gc.autoPackLimit.

gc.autoPackLimit

See the gc.bigPackThreshold configuration variable below. When in use, it’ll affect how the auto pack limit works.

gc.autoDetach

gc.bigPackThreshold

Note that if the number of kept packs is more than gc.autoPackLimit, this configuration variable is ignored, all packs except the base pack will be repacked. After this the number of packs should go below gc.autoPackLimit and gc.bigPackThreshold should be respected again.

If the amount of memory estimated for git repack to run smoothly is not available and gc.bigPackThreshold is not set, the largest pack will also be excluded (this is the equivalent of running git gc with --keep-largest-pack).

gc.writeCommitGraph

gc.logExpiry

gc.packRefs

gc.cruftPacks

gc.maxCruftSize

gc.pruneExpire

gc.worktreePruneExpire

gc.reflogExpire, gc.<pattern>.reflogExpire

gc.reflogExpireUnreachable, gc.<pattern>.reflogExpireUnreachable

These types of entries are generally created as a result of using git commit --amend or git rebase and are the commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner, which is why the default is more aggressive than gc.reflogExpire.

gc.recentObjectsHook

Output must contain exactly one hex object ID per line, and nothing else. Objects which cannot be found in the repository are ignored. Multiple hooks are supported, but all must exit successfully, else the operation (either generating a cruft pack or unpacking unreachable objects) will be halted.

gc.repackFilter

gc.repackFilterTo

gc.rerereResolved

gc.rerereUnresolved

gitcvs.commitMsgAnnotation

gitcvs.enabled

gitcvs.logFile

gitcvs.usecrlfattr

gitcvs.allBinary

gitcvs.dbName

gitcvs.dbDriver

gitcvs.dbUser, gitcvs.dbPass

gitcvs.dbTableNamePrefix

All gitcvs variables except for gitcvs.usecrlfattr and gitcvs.allBinary can also be specified as gitcvs.<access_method>.<varname> (where access_method is one of "ext" and "pserver") to make them apply only for the given access method.

gitweb.category, gitweb.description, gitweb.owner, gitweb.url

gitweb.avatar, gitweb.blame, gitweb.grep, gitweb.highlight, gitweb.patches, gitweb.pickaxe, gitweb.remote_heads, gitweb.showSizes, gitweb.snapshot

gpg.program

gpg.format

See gitformat-signature(5) for the signature format, which differs based on the selected gpg.format.

gpg.<format>.program

gpg.minTrustLevel

gpg.ssh.defaultKeyCommand

gpg.ssh.allowedSignersFile

SSH has no concept of trust levels like gpg does. To be able to differentiate between valid signatures and trusted signatures the trust level of a signature verification is set to fully when the public key is present in the allowedSignersFile. Otherwise the trust level is undefined and git verify-commit/tag will fail.

This file can be set to a location outside of the repository and every developer maintains their own trust store. A central repository server could generate this file automatically from ssh keys with push access to verify the code against. In a corporate setting this file is probably generated at a global location from automation that already handles developer ssh keys.

A repository that only allows signed commits can store the file in the repository itself using a path relative to the top-level of the working tree. This way only committers with an already valid key can add or change keys in the keyring.

Since OpensSSH 8.8 this file allows specifying a key lifetime using valid-after & valid-before options. Git will mark signatures as valid if the signing key was valid at the time of the signature’s creation. This allows users to change a signing key without invalidating all previously made signatures.

Using a SSH CA key with the cert-authority option (see ssh-keygen(1) "CERTIFICATES") is also valid.

gpg.ssh.revocationFile

grep.lineNumber

grep.column

grep.patternType

grep.extendedRegexp

grep.threads

grep.fullName

grep.fallbackToNoIndex

gui.commitMsgWidth

gui.diffContext

gui.displayUntracked

gui.encoding

gui.matchTrackingBranch

gui.newBranchTemplate

gui.pruneDuringFetch

gui.trustmtime

gui.spellingDictionary

gui.fastCopyBlame

gui.copyBlameThreshold

gui.blamehistoryctx

guitool.<name>.cmd

guitool.<name>.needsFile

guitool.<name>.noConsole

guitool.<name>.noRescan

guitool.<name>.confirm

guitool.<name>.argPrompt

guitool.<name>.revPrompt

guitool.<name>.revUnmerged

guitool.<name>.title

guitool.<name>.prompt

help.browser

help.format

help.autoCorrect

help.htmlPath

http.proxy

Any proxy, however configured, must be completely transparent and must not modify, transform, or buffer the request or response in any way. Proxies which are not completely transparent are known to cause various forms of breakage with Git.

http.proxyAuthMethod

http.proxySSLCert

http.proxySSLKey

http.proxySSLCertPasswordProtected

http.proxySSLCAInfo

http.emptyAuth

http.proactiveAuth

If the credential helper used specifies an authentication scheme (i.e., via the authtype field), that value will be used; if a username and password is provided without a scheme, then Basic authentication is used. The value of the option determines the scheme requested from the helper. Possible values are:

Note that TLS should always be used with this configuration, since otherwise it is easy to accidentally expose plaintext credentials if Basic authentication is selected.

http.delegation

http.extraHeader

http.cookieFile

http.saveCookies

http.version

http.curloptResolve

The first format redirects all requests to the given HOST:PORT to the provided ADDRESS(s). The second format clears all previous config values for that HOST:PORT combination. To allow easy overriding of all the settings inherited from the system config, an empty value will reset all resolution information to the empty list.

http.sslVersion

Can be overridden by the GIT_SSL_VERSION environment variable. To force git to use libcurl’s default ssl version and ignore any explicit http.sslversion option, set GIT_SSL_VERSION to the empty string.

http.sslCipherList

Can be overridden by the GIT_SSL_CIPHER_LIST environment variable. To force git to use libcurl’s default cipher list and ignore any explicit http.sslCipherList option, set GIT_SSL_CIPHER_LIST to the empty string.

http.sslVerify

http.sslCert

http.sslKey

http.sslCertPasswordProtected

http.sslCAInfo

http.sslCAPath

http.sslBackend

http.schannelCheckRevoke

http.schannelUseSSLCAInfo

http.pinnedPubkey

http.sslTry

http.maxRequests

http.minSessions

http.postBuffer

Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

http.lowSpeedLimit, http.lowSpeedTime

http.noEPSV

http.userAgent

http.followRedirects

http.<url>.*

The list above is ordered by decreasing precedence; a URL that matches a config key’s path is preferred to one that matches its user name. For example, if the URL is https://[email protected]/foo/bar a config key match of https://example.com/foo will be preferred over a config key match of https://[email protected].

All URLs are normalized before attempting any matching (the password part, if embedded in the URL, is always ignored for matching purposes) so that equivalent URLs that are simply spelled differently will match properly. Environment variable settings always override any matches. The URLs that are matched against are those given directly to Git commands. This means any URLs visited as a result of a redirection do not participate in matching.

i18n.commitEncoding

i18n.logOutputEncoding

imap.folder

imap.tunnel

imap.host

imap.user

imap.pass

imap.port

imap.sslverify

imap.preformattedHTML

imap.authMethod

include.path, includeIf.<condition>.path

index.recordEndOfIndexEntries

index.recordOffsetTable

index.sparse

index.threads

index.version

index.skipHash

If you enable index.skipHash, then Git clients older than 2.13.0 will refuse to parse the index and Git clients older than 2.40.0 will report an error during git fsck.

init.templateDir

init.defaultBranch

init.defaultObjectFormat

init.defaultRefFormat

instaweb.browser

instaweb.httpd

instaweb.local

instaweb.modulePath

instaweb.port

interactive.singleKey

interactive.diffFilter

log.abbrevCommit

log.date

If the format is set to "auto:foo" and the pager is in use, format "foo" will be used for the date format. Otherwise, "default" will be used.

log.decorate

log.initialDecorationSet

log.excludeDecoration

log.diffMerges

log.follow

log.graphColors

log.showRoot

log.showSignature

log.mailmap

lsrefs.unborn

mailinfo.scissors

mailmap.file

mailmap.blob

maintenance.auto

maintenance.autoDetach

If unset, the value of gc.autoDetach is used as a fallback. Defaults to true if both are unset, meaning that the maintenance process will detach.

maintenance.strategy

maintenance.<task>.enabled

maintenance.<task>.schedule

maintenance.commit-graph.auto

maintenance.loose-objects.auto

maintenance.incremental-repack.auto

man.viewer

man.<tool>.cmd

man.<tool>.path

merge.conflictStyle

merge.defaultToUpstream

merge.ff

merge.verifySignatures

merge.branchdesc

merge.log

merge.suppressDest

An element with an empty value can be used to clear the list of globs accumulated from previous configuration entries. When there is no merge.suppressDest variable defined, the default value of master is used for backward compatibility.

merge.renameLimit

merge.renames

merge.directoryRenames

merge.renormalize

merge.stat

merge.autoStash

merge.tool

merge.guitool

araxis

bc

bc3

bc4

codecompare

deltawalker

diffmerge

diffuse

ecmerge

emerge

examdiff

guiffy

gvimdiff

gvimdiff1

gvimdiff2

gvimdiff3

kdiff3

meld

nvimdiff

nvimdiff1

nvimdiff2

nvimdiff3

opendiff

p4merge

smerge

tkdiff

tortoisemerge

vimdiff

vimdiff1

vimdiff2

vimdiff3

vscode

winmerge

xxdiff

merge.verbosity

merge.<driver>.name

merge.<driver>.driver

merge.<driver>.recursive

mergetool.<tool>.path

mergetool.<tool>.cmd

mergetool.<tool>.hideResolved

mergetool.<tool>.trustExitCode

mergetool.meld.hasOutput

mergetool.meld.useAutoMerge

mergetool.<vimdiff variant>.layout

mergetool.hideResolved

mergetool.keepBackup

mergetool.keepTemporaries

mergetool.writeToTemp

mergetool.prompt

mergetool.guiDefault

notes.mergeStrategy

This setting can be overridden by passing the --strategy option to git-notes(1).

notes.<name>.mergeStrategy

notes.displayRef

This setting can be overridden with the GIT_NOTES_DISPLAY_REF environment variable, which must be a colon separated list of refs or globs.

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 disabled by the --no-notes option to the git log family of commands, or by the --notes=<ref> option accepted by those commands.

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>

This setting can be overridden with the GIT_NOTES_REWRITE_REF environment variable, which must be a colon separated list of refs or globs.

notes.rewriteMode

This setting can be overridden with the GIT_NOTES_REWRITE_MODE environment variable.

notes.rewriteRef

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.

Can be overridden with the GIT_NOTES_REWRITE_REF environment variable. See notes.rewrite.<command> above for a further description of its format.

pack.window

pack.depth

pack.windowMemory

pack.compression

Note that changing the compression level will not automatically recompress all existing objects. You can force recompression by passing the -F option to git-repack(1).

pack.allowPackReuse

If only a single pack bitmap is available, and pack.allowPackReuse is set to "multi", reuse parts of just the bitmapped packfile. This can reduce memory and CPU usage to serve fetches, but might result in sending a slightly larger pack. Defaults to true.

pack.island

pack.islandCore

pack.deltaCacheSize

pack.deltaCacheLimit

pack.threads

pack.indexVersion

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 git-index-pack(1) on the *.pack file to regenerate the *.idx file.

pack.packSizeLimit

Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).

If you need to actively run Git using smaller packfiles (e.g., because your filesystem does not support large files), this option may help. But if your goal is to transmit a packfile over a medium that supports limited sizes (e.g., removable media that cannot store the whole repository), you are likely better off creating a single large packfile and splitting it using a generic multi-volume archive tool (e.g., Unix split).

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

pack.useBitmapBoundaryTraversal

When using this algorithm, Git may include too many objects as a result of not opening up trees belonging to certain UNINTERESTING commits. This inexactness matches the non-bitmap traversal algorithm.

In many cases, this can provide a speed-up over the exact algorithm, particularly when there is poor bitmap coverage of the negated side of the query.

pack.useSparse

pack.preferBitmapTips

Note that setting this configuration to refs/foo does not mean that the commits at the tips of refs/foo/bar and refs/foo/baz will necessarily be selected. This is because commits are selected for bitmaps from within a series of windows of variable length.

If a commit at the tip of any reference which is a suffix of any value of this configuration is seen in a window, it is immediately given preference over any other commit in that window.

pack.writeBitmaps (deprecated)

pack.writeBitmapHashCache

When writing a multi-pack reachability bitmap, no new namehashes are computed; instead, any namehashes stored in an existing bitmap are permuted into their appropriate location when writing a new bitmap.

pack.writeBitmapLookupTable

pack.readReverseIndex

pack.writeReverseIndex

pager.<cmd>

pretty.<name>

promisor.quiet

protocol.allow

protocol.<name>.allow

The protocol names currently used by git are:

protocol.version

pull.ff

pull.rebase

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

pull.octopus

pull.twohead

push.autoSetupRemote

push.default

If you are working on a centralized workflow (pushing to the same repository you pull from, which is typically origin), then you need to configure an upstream branch with the same name.

This mode is the default since Git 2.0, and is the safest option suited for beginners.

To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.

This used to be the default, but not since Git 2.0 (simple is the new default).

push.followTags

push.gpgSign

push.pushOption

This is a multi-valued variable, and an empty value can be used in a higher priority configuration file (e.g. .git/config in a repository) to clear the values inherited from a lower priority configuration files (e.g. $HOME/.gitconfig).

Example:
/etc/gitconfig
\n
  push.pushoption = a
\n
  push.pushoption = b
~/.gitconfig
\n
  push.pushoption = c
repo/.git/config
\n
  push.pushoption =
\n
  push.pushoption = b
This will result in only b (a and c are cleared).

push.recurseSubmodules

push.useForceIfIncludes

push.negotiate

push.useBitmaps

rebase.backend

rebase.stat

rebase.autoSquash

rebase.autoStash

rebase.updateRefs

rebase.missingCommitsCheck

rebase.instructionFormat

rebase.abbreviateCommands

\n
        p deadbee The oneline of the commit
\n
        p fa1afe1 The oneline of the next commit
\n
        ...

instead of:

\n
        pick deadbee The oneline of the commit
\n
        pick fa1afe1 The oneline of the next commit
\n
        ...

Defaults to false.

rebase.rescheduleFailedExec

rebase.forkPoint

rebase.rebaseMerges

rebase.maxLabelLength

receive.advertiseAtomic

receive.advertisePushOptions

receive.autogc

receive.certNonceSeed

receive.certNonceSlop

receive.fsckObjects

receive.fsck.<msg-id>

receive.fsck.skipList

receive.keepAlive

receive.unpackLimit

receive.maxInputSize

receive.denyDeletes

receive.denyDeleteCurrent

receive.denyCurrentBranch

Another option is "updateInstead" which will update the working tree if pushing into the current branch. This option is intended for synchronizing working directories when one side is not easily accessible via interactive ssh (e.g. a live web site, hence the requirement that the working directory be clean). This mode also comes in handy when developing inside a VM to test and fix code on different Operating Systems.

By default, "updateInstead" will refuse the push if the working tree or the index have any difference from the HEAD, but the push-to-checkout hook can be used to customize this. See githooks(5).

receive.denyNonFastForwards

receive.hideRefs

receive.procReceiveRefs

For example, if this variable is set to "refs/for", pushing to reference such as "refs/for/master" will not create or update a reference named "refs/for/master", but may create or update a pull request directly by running the hook "proc-receive".

Optional modifiers can be provided in the beginning of the value to filter commands for specific actions: create (a), modify (m), delete (d). A ! can be included in the modifiers to negate the reference prefix entry. E.g.:

git config --system --add receive.procReceiveRefs ad:refs/heads
git config --system --add receive.procReceiveRefs !:refs/heads

receive.updateServerInfo

receive.shallowUpdate

reftable.blockSize

Powers of two that are friendly to the virtual memory system or filesystem (such as 4kB or 8kB) are recommended. Larger sizes (64kB) can yield better compression, with a possible increased cost incurred by readers during access.

The largest block size is 16777215 bytes (15.99 MiB). The default value is 4096 bytes (4kB). A value of 0 will use the default value.

reftable.restartInterval

More frequent restart points reduces prefix compression and increases space consumed by the restart table, both of which increase file size.

Less frequent restart points makes prefix compression more effective, decreasing overall file size, with increased penalties for readers walking through more records after the binary search step.

A maximum of 65535 restart points per block is supported.

The default value is to create restart points every 16 records. A value of 0 will use the default value.

reftable.indexObjects

The default value is true.

reftable.geometricFactor

By default, the geometric sequence uses a factor of 2, meaning that for any table, the next-biggest table must at least be twice as big. A maximum factor of 256 is supported.

reftable.lockTimeout

remote.pushDefault

remote.<name>.url

remote.<name>.pushurl

remote.<name>.proxy

remote.<name>.proxyAuthMethod

remote.<name>.fetch

remote.<name>.push

remote.<name>.mirror

remote.<name>.skipDefaultUpdate

remote.<name>.skipFetchAll

remote.<name>.receivepack

remote.<name>.uploadpack

remote.<name>.tagOpt

remote.<name>.vcs

remote.<name>.prune

remote.<name>.pruneTags

See also remote.<name>.prune and the PRUNING section of git-fetch(1).

remote.<name>.promisor

remote.<name>.partialclonefilter

remotes.<group>

repack.useDeltaBaseOffset

repack.packKeptObjects

repack.useDeltaIslands

repack.writeBitmaps

repack.updateServerInfo

repack.cruftWindow, repack.cruftWindowMemory, repack.cruftDepth, repack.cruftThreads

rerere.autoUpdate

rerere.enabled

revert.reference

safe.bareRepository

If you do not use bare repositories in your workflow, then it may be beneficial to set safe.bareRepository to explicit in your global config. This will protect you from attacks that involve cloning a repository that contains a bare repository and running a Git command within that directory.

This config setting is only respected in protected configuration (see the section called “SCOPES”). This prevents untrusted repositories from tampering with this value.

safe.directory

This is a multi-valued setting, i.e. you can add more than one directory via git config --add. To reset the list of safe directories (e.g. to override any such directories specified in the system config), add a safe.directory entry with an empty value.

This config setting is only respected in protected configuration (see the section called “SCOPES”). This prevents untrusted repositories from tampering with this value.

The value of this setting is interpolated, i.e. ~/<path> expands to a path relative to the home directory and %(prefix)/<path> expands to a path relative to Git’s (runtime) prefix.

To completely opt-out of this security check, set safe.directory to the string *. This will allow all repositories to be treated as if their directory was listed in the safe.directory list. If safe.directory=* is set in system config and you want to re-enable this protection, then initialize your list with an empty value before listing the repositories that you deem safe. Giving a directory with /* appended to it will allow access to all repositories under the named directory.

As explained, Git only allows you to access repositories owned by yourself, i.e. the user who is running Git, by default. When Git is running as root in a non Windows platform that provides sudo, however, git checks the SUDO_UID environment variable that sudo creates and will allow access to the uid recorded as its value in addition to the id from root. This is to make it easy to perform a common sequence during installation "make && sudo make install". A git process running under sudo runs as root but the sudo command exports the environment variable to record which id the original user has. If that is not what you would prefer and want git to only trust repositories that are owned by root instead, then you can remove the SUDO_UID variable from root’s environment before invoking git.

sendemail.identity

sendemail.smtpEncryption

sendemail.smtpSSLCertPath

sendemail.<identity>.*

sendemail.multiEdit

sendemail.confirm

sendemail.mailmap

sendemail.mailmap.file

sendemail.mailmap.blob

sendemail.aliasesFile

sendemail.aliasFileType

What an alias file in each format looks like can be found in the documentation of the email program of the same name. The differences and limitations from the standard formats are described below:

sendmail

sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd, sendemail.chainReplyTo, sendemail.envelopeSender, sendemail.from, sendemail.headerCmd, sendemail.signedOffByCc, sendemail.smtpPass, sendemail.suppressCc, sendemail.suppressFrom, sendemail.to, sendemail.toCmd, sendemail.smtpDomain, sendemail.smtpServer, sendemail.smtpServerPort, sendemail.smtpServerOption, sendemail.smtpUser, sendemail.thread, sendemail.transferEncoding, sendemail.validate, sendemail.xmailer

sendemail.signedOffCc (deprecated)

sendemail.smtpBatchSize

sendemail.smtpReloginDelay

sendemail.forbidSendmailVariables

sequence.editor

showBranch.default

sparse.expectFilesOutsideOfPatterns

The default is false, which allows Git to automatically recover from the list of files in the index and working tree falling out of sync.

Set this to true if you are in a setup where some external factor relieves Git of the responsibility for maintaining the consistency between the presence of working tree files and sparsity patterns. For example, if you have a Git-aware virtual file system that has a robust mechanism for keeping the working tree and the sparsity patterns up to date based on access patterns.

Regardless of this setting, Git does not check for present-despite-skipped files unless sparse checkout is enabled, so this config option has no effect unless core.sparseCheckout is true.

splitIndex.maxPercentChange

splitIndex.sharedIndexExpire

ssh.variant

The config variable ssh.variant can be set to override this detection. Valid values are ssh (to use OpenSSH options), plink, putty, tortoiseplink, simple (no options except the host and remote command). The default auto-detection can be explicitly requested using the value auto. Any other value is treated as ssh. This setting can also be overridden via the environment variable GIT_SSH_VARIANT.

The current command-line parameters used for each variant are as follows:

Except for the simple variant, command-line parameters are likely to change as git gains new features.

stash.showIncludeUntracked

stash.showPatch

stash.showStat

status.relativePaths

status.short

status.branch

status.aheadBehind

status.displayCommentPrefix

status.renameLimit

status.renames

status.showStash

status.showUntrackedFiles

If this variable is not specified, it defaults to normal. All usual spellings for Boolean value true are taken as normal and false as no. This variable can be overridden with the -u|--untracked-files option of git-status(1) and git-commit(1).

status.submoduleSummary

submodule.<name>.url

submodule.<name>.update

submodule.<name>.branch

submodule.<name>.fetchRecurseSubmodules

submodule.<name>.ignore

submodule.<name>.active

submodule.active

submodule.recurse

When set to true, it can be deactivated via the --no-recurse-submodules option. Note that some Git commands lacking this option may call some of the above commands affected by submodule.recurse; for instance git remote update will call git fetch but does not have a --no-recurse-submodules option. For these commands a workaround is to temporarily change the configuration value by using git -c submodule.recurse=0.

The following list shows the commands that accept --recurse-submodules and whether they are supported by this setting.

submodule.propagateBranches

submodule.fetchJobs

submodule.alternateLocation

submodule.alternateErrorStrategy

tag.forceSignAnnotated

tag.sort

tag.gpgSign

tar.umask

Trace2 config settings are only read from the system and global config files; repository local and worktree config files and -c command line arguments are not respected.

trace2.normalTarget

trace2.perfTarget

trace2.eventTarget

trace2.normalBrief

trace2.perfBrief

trace2.eventBrief

trace2.eventNesting

trace2.configParams

trace2.envVars

trace2.destinationDebug

trace2.maxFiles

transfer.credentialsInUrl

Note that this is currently limited to detecting credentials in remote.<name>.url configuration; it won’t detect credentials in remote.<name>.pushurl configuration.

You might want to enable this to prevent inadvertent credentials exposure, e.g. because:

If such concerns don’t apply to you then you probably don’t need to be concerned about credentials exposure due to storing sensitive data in git’s configuration files. If you do want to use this, set transfer.credentialsInUrl to one of these values:

transfer.fsckObjects

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 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 cannot 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

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. In order to match refs before stripping, add a ^ in front of the ref name. If you combine ! and ^, ! must be specified first.

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. If uploadpack.allowRefInWant is set, upload-pack will treat want-ref refs/heads/master in a protocol v2 fetch command as if refs/namespaces/foo/refs/heads/master did not exist. receive-pack, on the other hand, will still advertise the object id the ref is pointing to without mentioning its name (a so-called ".have" line).

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 gitnamespaces(7) man page; it’s best to keep private data in a separate repository.

transfer.unpackLimit

transfer.advertiseSID

transfer.bundleURI

transfer.advertiseObjectInfo

uploadarchive.allowUnreachable

uploadpack.hideRefs

uploadpack.allowTipSHA1InWant

uploadpack.allowReachableSHA1InWant

uploadpack.allowAnySHA1InWant

uploadpack.keepAlive

uploadpack.packObjectsHook

Note that this configuration variable is only respected when it is specified in protected configuration (see the section called “SCOPES”). This is a safety measure against fetching from untrusted repositories.

uploadpack.allowFilter

uploadpackfilter.allow

uploadpackfilter.<filter>.allow

uploadpackfilter.tree.maxDepth

uploadpack.allowRefInWant

url.<base>.insteadOf

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

user.name, user.email, author.name, author.email, committer.name, committer.email

Note that the name forms of these variables conventionally refer to some form of a personal name. See git-commit(1) and the environment variables section of git(1) for more information on these settings and the credential.username option if you’re looking for authentication credentials instead.

user.useConfigOnly

user.signingKey

versionsort.prereleaseSuffix (deprecated)

versionsort.suffix

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 suffix matches 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 suffix starts 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

worktree.guessRemote

BUGS#

When using the deprecated [section.subsection] syntax, changing a value will result in adding a multi-line key instead of a change, if the subsection is given with at least one uppercase character. For example when the config looks like

\n
  [section.subsection]
\n
    key = value1

and running git config section.Subsection.key value2 will result in

\n
  [section.subsection]
\n
    key = value1
\n
    key = value2

GIT#

Part of the git(1) suite

NOTES#

1.

the bundle URI design document