{ "mode": "man", "parameter": "GIT-CONFIG", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/GIT-CONFIG/1/json", "generated": "2026-07-05T11:57:07Z", "synopsis": "git config [] [--type=] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] name [value [value-pattern]]\ngit config [] [--type=] --add name value\ngit config [] [--type=] [--fixed-value] --replace-all name value [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get name [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all name [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp nameregex [value-pattern]\ngit config [] [--type=] [-z|--null] --get-urlmatch name URL\ngit config [] [--fixed-value] --unset name [value-pattern]\ngit config [] [--fixed-value] --unset-all name [value-pattern]\ngit config [] --rename-section oldname newname\ngit config [] --remove-section name\ngit config [] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list\ngit config [] --get-color name [default]\ngit config [] --get-colorbool name [stdout-is-tty]\ngit config [] -e | --edit", "sections": { "NAME": { "content": "git-config - Get and set repository or global options\n", "subsections": [] }, "SYNOPSIS": { "content": "git config [] [--type=] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] name [value [value-pattern]]\ngit config [] [--type=] --add name value\ngit config [] [--type=] [--fixed-value] --replace-all name value [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get name [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all name [value-pattern]\ngit config [] [--type=] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp nameregex [value-pattern]\ngit config [] [--type=] [-z|--null] --get-urlmatch name URL\ngit config [] [--fixed-value] --unset name [value-pattern]\ngit config [] [--fixed-value] --unset-all name [value-pattern]\ngit config [] --rename-section oldname newname\ngit config [] --remove-section name\ngit config [] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list\ngit config [] --get-color name [default]\ngit config [] --get-colorbool name [stdout-is-tty]\ngit config [] -e | --edit\n\n", "subsections": [] }, "DESCRIPTION": { "content": "You can query/set/replace/unset options with this command. The name is actually the section\nand the key separated by a dot, and the value will be escaped.\n\nMultiple lines can be added to an option by using the --add option. If you want to update or\nunset an option which can occur on multiple lines, a value-pattern (which is an extended\nregular expression, unless the --fixed-value option is given) needs to be given. Only the\nexisting values that match the pattern are updated or unset. If you want to handle the lines\nthat do not match the pattern, just prepend a single exclamation mark in front (see also the\nsection called “EXAMPLES”), but note that this only works when the --fixed-value option is\nnot in use.\n\nThe --type= option instructs git config to ensure that incoming and outgoing values are\ncanonicalize-able under the given . If no --type= is given, no canonicalization\nwill be performed. Callers may unset an existing --type specifier with --no-type.\n\nWhen reading, the values are read from the system, global and repository local configuration\nfiles by default, and options --system, --global, --local, --worktree and --file \ncan be used to tell the command to read from only that location (see the section called\n“FILES”).\n\nWhen writing, the new value is written to the repository local configuration file by default,\nand options --system, --global, --worktree, --file can be used to tell the command\nto write to that location (you can say --local but that is the default).\n\nThis command will fail with non-zero status upon error. Some exit codes are:\n\n• The section or key is invalid (ret=1),\n\n• no section or name was provided (ret=2),\n\n• the config file is invalid (ret=3),\n\n• the config file cannot be written (ret=4),\n\n• you try to unset an option which does not exist (ret=5),\n\n• you try to unset/set an option for which multiple lines match (ret=5), or\n\n• you try to use an invalid regexp (ret=6).\n\nOn success, the command returns the exit code 0.\n\nA list of all available configuration variables can be obtained using the git help --config\ncommand.\n", "subsections": [] }, "OPTIONS": { "content": "", "subsections": [ { "name": "--replace-all", "content": "Default behavior is to replace at most one line. This replaces all lines matching the key\n(and optionally the value-pattern).\n", "long": "--replace-all" }, { "name": "--add", "content": "Adds a new line to the option without altering any existing values. This is the same as\nproviding ^$ as the value-pattern in --replace-all.\n", "long": "--add" }, { "name": "--get", "content": "Get the value for a given key (optionally filtered by a regex matching the value).\nReturns error code 1 if the key was not found and the last value if multiple key values\nwere found.\n", "long": "--get" }, { "name": "--get-all", "content": "Like get, but returns all values for a multi-valued key.\n", "long": "--get-all" }, { "name": "--get-regexp", "content": "Like --get-all, but interprets the name as a regular expression and writes out the key\nnames. Regular expression matching is currently case-sensitive and done against a\ncanonicalized version of the key in which section and variable names are lowercased, but\nsubsection names are not.\n\n--get-urlmatch name URL\nWhen given a two-part name section.key, the value for section..key whose part\nmatches the best to the given URL is returned (if no such key exists, the value for\nsection.key is used as a fallback). When given just the section as name, do so for all\nthe keys in the section and list them. Returns error code 1 if no value is found.\n", "long": "--get-regexp" }, { "name": "--global", "content": "For writing options: write to global ~/.gitconfig file rather than the repository\n.git/config, write to $XDGCONFIGHOME/git/config file if this file exists and the\n~/.gitconfig file doesn’t.\n\nFor reading options: read only from global ~/.gitconfig and from\n$XDGCONFIGHOME/git/config rather than from all available files.\n\nSee also the section called “FILES”.\n", "long": "--global" }, { "name": "--system", "content": "For writing options: write to system-wide $(prefix)/etc/gitconfig rather than the\nrepository .git/config.\n\nFor reading options: read only from system-wide $(prefix)/etc/gitconfig rather than from\nall available files.\n\nSee also the section called “FILES”.\n", "long": "--system" }, { "name": "--local", "content": "For writing options: write to the repository .git/config file. This is the default\nbehavior.\n\nFor reading options: read only from the repository .git/config rather than from all\navailable files.\n\nSee also the section called “FILES”.\n", "long": "--local" }, { "name": "--worktree", "content": "Similar to --local except that .git/config.worktree is read from or written to if\nextensions.worktreeConfig is present. If not it’s the same as --local.\n\n-f config-file, --file config-file\nFor writing options: write to the specified file rather than the repository .git/config.\n\nFor reading options: read only from the specified file rather than from all available\nfiles.\n\nSee also the section called “FILES”.\n\n--blob blob\nSimilar to --file but use the given blob instead of a file. E.g. you can use\nmaster:.gitmodules to read values from the file .gitmodules in the master branch. See\n\"SPECIFYING REVISIONS\" section in gitrevisions(7) for a more complete list of ways to\nspell blob names.\n", "long": "--worktree" }, { "name": "--remove-section", "content": "Remove the given section from the configuration file.\n", "long": "--remove-section" }, { "name": "--rename-section", "content": "Rename the given section to a new name.\n", "long": "--rename-section" }, { "name": "--unset", "content": "Remove the line matching the key from config file.\n", "long": "--unset" }, { "name": "--unset-all", "content": "Remove all lines matching the key from config file.\n", "long": "--unset-all" }, { "name": "-l, --list", "content": "List all variables set in config file, along with their values.\n", "flag": "-l", "long": "--list" }, { "name": "--fixed-value", "content": "When used with the value-pattern argument, treat value-pattern as an exact string instead\nof a regular expression. This will restrict the name/value pairs that are matched to only\nthose where the value is exactly equal to the value-pattern.\n", "long": "--fixed-value" }, { "name": "--type ", "content": "git config will ensure that any input or output is valid under the given type\nconstraint(s), and will canonicalize outgoing values in 's canonical form.\n\nValid 's include:\n\n• bool: canonicalize values as either \"true\" or \"false\".\n\n• int: canonicalize values as simple decimal numbers. An optional suffix of k, m, or g\nwill cause the value to be multiplied by 1024, 1048576, or 1073741824 upon input.\n\n• bool-or-int: canonicalize according to either bool or int, as described above.\n\n• path: canonicalize by adding a leading ~ to the value of $HOME and ~user to the home\ndirectory for the specified user. This specifier has no effect when setting the value\n(but you can use git config section.variable ~/ from the command line to let your\nshell do the expansion.)\n\n• expiry-date: canonicalize by converting from a fixed or relative date-string to a\ntimestamp. This specifier has no effect when setting the value.\n\n• color: When getting a value, canonicalize by converting to an ANSI color escape\nsequence. When setting a value, a sanity-check is performed to ensure that the given\nvalue is canonicalize-able as an ANSI color, but it is written as-is.\n", "long": "--type", "arg": "" }, { "name": "--bool, --int, --bool-or-int, --path, --expiry-date", "content": "Historical options for selecting a type specifier. Prefer instead --type (see above).\n", "long": "--expiry-date" }, { "name": "--no-type", "content": "Un-sets the previously set type specifier (if one was previously set). This option\nrequests that git config not canonicalize the retrieved variable. --no-type has no\neffect without --type= or --.\n", "long": "--no-type" }, { "name": "-z, --null", "content": "For all options that output values and/or keys, always end values with the null character\n(instead of a newline). Use newline instead as a delimiter between key and value. This\nallows for secure parsing of the output without getting confused e.g. by values that\ncontain line breaks.\n", "flag": "-z", "long": "--null" }, { "name": "--name-only", "content": "Output only the names of config variables for --list or --get-regexp.\n", "long": "--name-only" }, { "name": "--show-origin", "content": "Augment the output of all queried config options with the origin type (file, standard\ninput, blob, command line) and the actual origin (config file path, ref, or blob id if\napplicable).\n", "long": "--show-origin" }, { "name": "--show-scope", "content": "Similar to --show-origin in that it augments the output of all queried config options\nwith the scope of that value (local, global, system, command).\n\n--get-colorbool name [stdout-is-tty]\nFind the color setting for name (e.g. color.diff) and output \"true\" or \"false\".\nstdout-is-tty should be either \"true\" or \"false\", and is taken into account when\nconfiguration says \"auto\". If stdout-is-tty is missing, then checks the standard output\nof the command itself, and exits with status 0 if color is to be used, or exits with\nstatus 1 otherwise. When the color setting for name is undefined, the command uses\ncolor.ui as fallback.\n\n--get-color name [default]\nFind the color configured for name (e.g. color.diff.new) and output it as the ANSI color\nescape sequence to the standard output. The optional default parameter is used instead,\nif there is no color configured for name.\n\n--type=color [--default=] is preferred over --get-color (but note that\n--get-color will omit the trailing newline printed by --type=color).\n", "long": "--show-scope" }, { "name": "-e, --edit", "content": "Opens an editor to modify the specified config file; either --system, --global, or\nrepository (default).\n\n--[no-]includes\nRespect include.* directives in config files when looking up values. Defaults to off\nwhen a specific file is given (e.g., using --file, --global, etc) and on when searching\nall config files.\n", "flag": "-e", "long": "--edit" }, { "name": "--default ", "content": "When using --get, and the requested variable is not found, behave as if were the\nvalue assigned to the that variable.\n", "long": "--default", "arg": "" } ] }, "CONFIGURATION": { "content": "pager.config is only respected when listing configuration, i.e., when using --list or any of\nthe --get-* which may return multiple results. The default is to use a pager.\n", "subsections": [] }, "FILES": { "content": "If not set explicitly with --file, there are four files where git config will search for\nconfiguration options:\n\n$(prefix)/etc/gitconfig\nSystem-wide configuration file.\n\n$XDGCONFIGHOME/git/config\nSecond user-specific configuration file. If $XDGCONFIGHOME is not set or empty,\n$HOME/.config/git/config will be used. Any single-valued variable set in this file will\nbe overwritten by whatever is in ~/.gitconfig. It is a good idea not to create this file\nif you sometimes use older versions of Git, as support for this file was added fairly\nrecently.\n\n~/.gitconfig\nUser-specific configuration file. Also called \"global\" configuration file.\n\n$GITDIR/config\nRepository specific configuration file.\n\n$GITDIR/config.worktree\nThis is optional and is only searched when extensions.worktreeConfig is present in\n$GITDIR/config.\n\nIf no further options are given, all reading options will read all of these files that are\navailable. If the global or the system-wide configuration file are not available they will be\nignored. If the repository configuration file is not available or readable, git config will\nexit with a non-zero error code. However, in neither case will an error message be issued.\n\nThe files are read in the order given above, with last value found taking precedence over\nvalues read earlier. When multiple values are taken then all values of a key from all files\nwill be used.\n\nYou may override individual configuration parameters when running any git command by using\nthe -c option. See git(1) for details.\n\nAll writing options will per default write to the repository specific configuration file.\nNote that this also affects options like --replace-all and --unset. git config will only ever\nchange one file at a time.\n\nYou can override these rules using the --global, --system, --local, --worktree, and --file\ncommand-line options; see the section called “OPTIONS” above.\n", "subsections": [] }, "ENVIRONMENT": { "content": "GITCONFIGGLOBAL, GITCONFIGSYSTEM\nTake the configuration from the given files instead from global or system-level\nconfiguration. See git(1) for details.\n\nGITCONFIGNOSYSTEM\nWhether to skip reading settings from the system-wide $(prefix)/etc/gitconfig file. See\ngit(1) for details.\n\nSee also the section called “FILES”.\n\nGITCONFIGCOUNT, GITCONFIGKEY, GITCONFIGVALUE\nIf GITCONFIGCOUNT is set to a positive number, all environment pairs GITCONFIGKEY\nand GITCONFIGVALUE up to that number will be added to the process’s runtime\nconfiguration. The config pairs are zero-indexed. Any missing key or value is treated as\nan error. An empty GITCONFIGCOUNT is treated the same as GITCONFIGCOUNT=0, namely no\npairs are processed. These environment variables will override values in configuration\nfiles, but will be overridden by any explicit options passed via git -c.\n\nThis is useful for cases where you want to spawn multiple git commands with a common\nconfiguration but cannot depend on a configuration file, for example when writing\nscripts.\n\nGITCONFIG\nIf no --file option is provided to git config, use the file given by GITCONFIG as if it\nwere provided via --file. This variable has no effect on other Git commands, and is\nmostly for historical compatibility; there is generally no reason to use it instead of\nthe --file option.\n", "subsections": [] }, "EXAMPLES": { "content": "Given a .git/config like this:\n\n#\n# This is the config file, and\n# a '#' or ';' character indicates\n# a comment\n#\n\n; core variables\n[core]\n; Don't trust file modes\nfilemode = false\n\n; Our diff algorithm\n[diff]\nexternal = /usr/local/bin/diff-wrapper\nrenames = true\n\n; Proxy settings\n[core]\ngitproxy=proxy-command for kernel.org\ngitproxy=default-proxy ; for all the rest\n\n; HTTP\n[http]\nsslVerify\n[http \"https://weak.example.com\"]\nsslVerify = false\ncookieFile = /tmp/cookie.txt\n\n\nyou can set the filemode to true with\n\n% git config core.filemode true\n\n\nThe hypothetical proxy command entries actually have a postfix to discern what URL they apply\nto. Here is how to change the entry for kernel.org to \"ssh\".\n\n% git config core.gitproxy '\"ssh\" for kernel.org' 'for kernel.org$'\n\n\nThis makes sure that only the key/value pair for kernel.org is replaced.\n\nTo delete the entry for renames, do\n\n% git config --unset diff.renames\n\n\nIf you want to delete an entry for a multivar (like core.gitproxy above), you have to provide\na regex matching the value of exactly one line.\n\nTo query the value for a given key, do\n\n% git config --get core.filemode\n\n\nor\n\n% git config core.filemode\n\n\nor, to query a multivar:\n\n% git config --get core.gitproxy \"for kernel.org$\"\n\n\nIf you want to know all the values for a multivar, do:\n\n% git config --get-all core.gitproxy\n\n\nIf you like to live dangerously, you can replace all core.gitproxy by a new one with\n\n% git config --replace-all core.gitproxy ssh\n\n\nHowever, if you really only want to replace the line for the default proxy, i.e. the one\nwithout a \"for ...\" postfix, do something like this:\n\n% git config core.gitproxy ssh '! for '\n\n\nTo actually match only values with an exclamation mark, you have to\n\n% git config section.key value '[!]'\n\n\nTo add a new proxy, without altering any of the existing ones, use\n\n% git config --add core.gitproxy '\"proxy-command\" for example.com'\n\n\nAn example to use customized color from the configuration in your script:\n\n#!/bin/sh\nWS=$(git config --get-color color.diff.whitespace \"blue reverse\")\nRESET=$(git config --get-color \"\" \"reset\")\necho \"${WS}your whitespace color or blue reverse${RESET}\"\n\n\nFor URLs in https://weak.example.com, http.sslVerify is set to false, while it is set to true\nfor all others:\n\n% git config --type=bool --get-urlmatch http.sslverify https://good.example.com\ntrue\n% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com\nfalse\n% git config --get-urlmatch http https://weak.example.com\nhttp.cookieFile /tmp/cookie.txt\nhttp.sslverify false\n\n", "subsections": [] }, "CONFIGURATION FILE": { "content": "The Git configuration file contains a number of variables that affect the Git commands'\nbehavior. The files .git/config and optionally config.worktree (see the \"CONFIGURATION FILE\"\nsection of git-worktree(1)) in each repository are used to store the configuration for that\nrepository, and $HOME/.gitconfig is used to store a per-user configuration as fallback values\nfor the .git/config file. The file /etc/gitconfig can be used to store a system-wide default\nconfiguration.\n\nThe configuration variables are used by both the Git plumbing and the porcelains. The\nvariables are divided into sections, wherein the fully qualified variable name of the\nvariable itself is the last dot-separated segment and the section name is everything before\nthe last dot. The variable names are case-insensitive, allow only alphanumeric characters and\n-, and must start with an alphabetic character. Some variables may appear multiple times; we\nsay then that the variable is multivalued.\n", "subsections": [ { "name": "Syntax", "content": "The syntax is fairly flexible and permissive; whitespaces are mostly ignored. The # and ;\ncharacters begin comments to the end of line, blank lines are ignored.\n\nThe file consists of sections and variables. A section begins with the name of the section in\nsquare brackets and continues until the next section begins. Section names are\ncase-insensitive. Only alphanumeric characters, - and . are allowed in section names. Each\nvariable must belong to some section, which means that there must be a section header before\nthe first setting of a variable.\n\nSections can be further divided into subsections. To begin a subsection put its name in\ndouble quotes, separated by space from the section name, in the section header, like in the\nexample below:\n\n[section \"subsection\"]\n\n\nSubsection names are case sensitive and can contain any characters except newline and the\nnull byte. Doublequote \" and backslash can be included by escaping them as \\\" and \\\\,\nrespectively. Backslashes preceding other characters are dropped when reading; for example,\n\\t is read as t and \\0 is read as 0. Section headers cannot span multiple lines. Variables\nmay belong directly to a section or to a given subsection. You can have [section] if you have\n[section \"subsection\"], but you don’t need to.\n\nThere is also a deprecated [section.subsection] syntax. With this syntax, the subsection name\nis converted to lower-case and is also compared case sensitively. These subsection names\nfollow the same restrictions as section names.\n\nAll the other lines (and the remainder of the line after the section header) are recognized\nas setting variables, in the form name = value (or just name, which is a short-hand to say\nthat the variable is the boolean \"true\"). The variable names are case-insensitive, allow only\nalphanumeric characters and -, and must start with an alphabetic character.\n\nA line that defines a value can be continued to the next line by ending it with a \\; the\nbackslash and the end-of-line are stripped. Leading whitespaces after name =, the remainder\nof the line after the first comment character # or ;, and trailing whitespaces of the line\nare discarded unless they are enclosed in double quotes. Internal whitespaces within the\nvalue are retained verbatim.\n\nInside double quotes, double quote \" and backslash \\ characters must be escaped: use \\\" for \"\nand \\\\ for \\.\n\nThe following escape sequences (beside \\\" and \\\\) are recognized: \\n for newline character\n(NL), \\t for horizontal tabulation (HT, TAB) and \\b for backspace (BS). Other char escape\nsequences (including octal escape sequences) are invalid.\n" }, { "name": "Includes", "content": "The include and includeIf sections allow you to include config directives from another\nsource. These sections behave identically to each other with the exception that includeIf\nsections may be ignored if their condition does not evaluate to true; see \"Conditional\nincludes\" below.\n\nYou can include a config file from another by setting the special include.path (or\nincludeIf.*.path) variable to the name of the file to be included. The variable takes a\npathname as its value, and is subject to tilde expansion. These variables can be given\nmultiple times.\n\nThe contents of the included file are inserted immediately, as if they had been found at the\nlocation of the include directive. If the value of the variable is a relative path, the path\nis considered to be relative to the configuration file in which the include directive was\nfound. See below for examples.\n" }, { "name": "Conditional includes", "content": "You can include a config file from another conditionally by setting a\nincludeIf..path variable to the name of the file to be included.\n\nThe condition starts with a keyword followed by a colon and some data whose format and\nmeaning depends on the keyword. Supported keywords are:\n" }, { "name": "gitdir", "content": "The data that follows the keyword gitdir: is used as a glob pattern. If the location of\nthe .git directory matches the pattern, the include condition is met.\n\nThe .git location may be auto-discovered, or come from $GITDIR environment variable. If\nthe repository is auto discovered via a .git file (e.g. from submodules, or a linked\nworktree), the .git location would be the final location where the .git directory is, not\nwhere the .git file is.\n\nThe pattern can contain standard globbing wildcards and two additional ones, / and /,\nthat can match multiple path components. Please refer to gitignore(5) for details. For\nconvenience:\n\n• If the pattern starts with ~/, ~ will be substituted with the content of the\nenvironment variable HOME.\n\n• If the pattern starts with ./, it is replaced with the directory containing the\ncurrent config file.\n\n• If the pattern does not start with either ~/, ./ or /, / will be automatically\nprepended. For example, the pattern foo/bar becomes /foo/bar and would match\n/any/path/to/foo/bar.\n\n• If the pattern ends with /, will be automatically added. For example, the pattern\nfoo/ becomes foo/. In other words, it matches \"foo\" and everything inside,\nrecursively.\n" }, { "name": "gitdir/i", "content": "This is the same as gitdir except that matching is done case-insensitively (e.g. on\ncase-insensitive file systems)\n" }, { "name": "onbranch", "content": "The data that follows the keyword onbranch: is taken to be a pattern with standard\nglobbing wildcards and two additional ones, / and /, that can match multiple path\ncomponents. If we are in a worktree where the name of the branch that is currently\nchecked out matches the pattern, the include condition is met.\n\nIf the pattern ends with /, will be automatically added. For example, the pattern foo/\nbecomes foo/. In other words, it matches all branches that begin with foo/. This is\nuseful if your branches are organized hierarchically and you would like to apply a\nconfiguration to all the branches in that hierarchy.\n\nA few more notes on matching via gitdir and gitdir/i:\n\n• Symlinks in $GITDIR are not resolved before matching.\n\n• Both the symlink & realpath versions of paths will be matched outside of $GITDIR. E.g.\nif ~/git is a symlink to /mnt/storage/git, both gitdir:~/git and gitdir:/mnt/storage/git\nwill match.\n\nThis was not the case in the initial release of this feature in v2.13.0, which only\nmatched the realpath version. Configuration that wants to be compatible with the initial\nrelease of this feature needs to either specify only the realpath version, or both\nversions.\n\n• Note that \"../\" is not special and will match literally, which is unlikely what you want.\n" }, { "name": "Example", "content": "# Core variables\n[core]\n; Don't trust file modes\nfilemode = false\n\n# Our diff algorithm\n[diff]\nexternal = /usr/local/bin/diff-wrapper\nrenames = true\n\n[branch \"devel\"]\nremote = origin\nmerge = refs/heads/devel\n\n# Proxy settings\n[core]\ngitProxy=\"ssh\" for \"kernel.org\"\ngitProxy=default-proxy ; for the rest\n\n[include]\npath = /path/to/foo.inc ; include by absolute path\npath = foo.inc ; find \"foo.inc\" relative to the current file\npath = ~/foo.inc ; find \"foo.inc\" in your `$HOME` directory\n\n; include if $GITDIR is /path/to/foo/.git\n[includeIf \"gitdir:/path/to/foo/.git\"]\npath = /path/to/foo.inc\n\n; include for all repositories inside /path/to/group\n[includeIf \"gitdir:/path/to/group/\"]\npath = /path/to/foo.inc\n\n; include for all repositories inside $HOME/to/group\n[includeIf \"gitdir:~/to/group/\"]\npath = /path/to/foo.inc\n\n; relative paths are always relative to the including\n; file (if the condition is true); their location is not\n; affected by the condition\n[includeIf \"gitdir:/path/to/group/\"]\npath = foo.inc\n\n; include only if we are in a worktree where foo-branch is\n; currently checked out\n[includeIf \"onbranch:foo-branch\"]\npath = foo.inc\n\n" }, { "name": "Values", "content": "Values of many variables are treated as a simple string, but there are variables that take\nvalues of specific types and there are rules as to how to spell them.\n\nboolean\nWhen a variable is said to take a boolean value, many synonyms are accepted for true and\nfalse; these are all case-insensitive.\n\ntrue\nBoolean true literals are yes, on, true, and 1. Also, a variable defined without =\n is taken as true.\n\nfalse\nBoolean false literals are no, off, false, 0 and the empty string.\n\nWhen converting a value to its canonical form using the --type=bool type specifier,\ngit config will ensure that the output is \"true\" or \"false\" (spelled in lowercase).\n\ninteger\nThe value for many variables that specify various sizes can be suffixed with k, M,... to\nmean \"scale the number by 1024\", \"by 1024x1024\", etc.\n\ncolor\nThe value for a variable that takes a color is a list of colors (at most two, one for\nforeground and one for background) and attributes (as many as you want), separated by\nspaces.\n\nThe basic colors accepted are normal, black, red, green, yellow, blue, magenta, cyan and\nwhite. The first color given is the foreground; the second is the background. All the\nbasic colors except normal have a bright variant that can be specified by prefixing the\ncolor with bright, like brightred.\n\nColors may also be given as numbers between 0 and 255; these use ANSI 256-color mode (but\nnote that not all terminals may support this). If your terminal supports it, you may also\nspecify 24-bit RGB values as hex, like #ff0ab3.\n\nThe accepted attributes are bold, dim, ul, blink, reverse, italic, and strike (for\ncrossed-out or \"strikethrough\" letters). The position of any attributes with respect to\nthe colors (before, after, or in between), doesn’t matter. Specific attributes may be\nturned off by prefixing them with no or no- (e.g., noreverse, no-ul, etc).\n\nAn empty color string produces no color effect at all. This can be used to avoid coloring\nspecific elements without disabling color entirely.\n\nFor git’s pre-defined color slots, the attributes are meant to be reset at the beginning\nof each item in the colored output. So setting color.decorate.branch to black will paint\nthat branch name in a plain black, even if the previous thing on the same output line\n(e.g. opening parenthesis before the list of branch names in log --decorate output) is\nset to be painted with bold or some other attribute. However, custom log formats may do\nmore complicated and layered coloring, and the negated forms may be useful there.\n\npathname\nA variable that takes a pathname value can be given a string that begins with \"~/\" or\n\"~user/\", and the usual tilde expansion happens to such a string: ~/ is expanded to the\nvalue of $HOME, and ~user/ to the specified user’s home directory.\n\nIf a path starts with %(prefix)/, the remainder is interpreted as a path relative to\nGit’s \"runtime prefix\", i.e. relative to the location where Git itself was installed. For\nexample, %(prefix)/bin/ refers to the directory in which the Git executable itself lives.\nIf Git was compiled without runtime prefix support, the compiled-in prefix will be\nsubstituted instead. In the unlikely event that a literal path needs to be specified that\nshould not be expanded, it needs to be prefixed by ./, like so: ./%(prefix)/bin.\n" }, { "name": "Variables", "content": "Note that this list is non-comprehensive and not necessarily complete. For command-specific\nvariables, you will find a more detailed description in the appropriate manual page.\n\nOther git-related tools may and do use their own variables. When inventing new variables for\nuse in your own tool, make sure their names do not conflict with those that are used by Git\nitself and other popular tools, and describe them in your documentation.\n\nadvice.*\nThese variables control various optional help messages designed to aid new users. All\nadvice.* variables default to true, and you can tell Git that you do not need help by\nsetting these to false:\n\nfetchShowForcedUpdates\nAdvice shown when git-fetch(1) takes a long time to calculate forced updates after\nref updates, or to warn that the check is disabled.\n\npushUpdateRejected\nSet this variable to false if you want to disable pushNonFFCurrent,\npushNonFFMatching, pushAlreadyExists, pushFetchFirst, pushNeedsForce, and\npushRefNeedsUpdate simultaneously.\n\npushNonFFCurrent\nAdvice shown when git-push(1) fails due to a non-fast-forward update to the current\nbranch.\n\npushNonFFMatching\nAdvice shown when you ran git-push(1) and pushed matching refs explicitly (i.e. you\nused :, or specified a refspec that isn’t your current branch) and it resulted in a\nnon-fast-forward error.\n\npushAlreadyExists\nShown when git-push(1) rejects an update that does not qualify for fast-forwarding\n(e.g., a tag.)\n\npushFetchFirst\nShown when git-push(1) rejects an update that tries to overwrite a remote ref that\npoints at an object we do not have.\n\npushNeedsForce\nShown when git-push(1) rejects an update that tries to overwrite a remote ref that\npoints at an object that is not a commit-ish, or make the remote ref point at an\nobject that is not a commit-ish.\n\npushUnqualifiedRefname\nShown when git-push(1) gives up trying to guess based on the source and destination\nrefs what remote ref namespace the source belongs in, but where we can still suggest\nthat the user push to either refs/heads/* or refs/tags/* based on the type of the\nsource object.\n\npushRefNeedsUpdate\nShown when git-push(1) rejects a forced update of a branch when its remote-tracking\nref has updates that we do not have locally.\n\nskippedCherryPicks\nShown when git-rebase(1) skips a commit that has already been cherry-picked onto the\nupstream branch.\n\nstatusAheadBehind\nShown when git-status(1) computes the ahead/behind counts for a local ref compared to\nits remote tracking ref, and that calculation takes longer than expected. Will not\nappear if status.aheadBehind is false or the option --no-ahead-behind is given.\n\nstatusHints\nShow directions on how to proceed from the current state in the output of git-\nstatus(1), in the template shown when writing commit messages in git-commit(1), and\nin the help message shown by git-switch(1) or git-checkout(1) when switching branch.\n\nstatusUoption\nAdvise to consider using the -u option to git-status(1) when the command takes more\nthan 2 seconds to enumerate untracked files.\n\ncommitBeforeMerge\nAdvice shown when git-merge(1) refuses to merge to avoid overwriting local changes.\n\nresetQuiet\nAdvice to consider using the --quiet option to git-reset(1) when the command takes\nmore than 2 seconds to enumerate unstaged changes after reset.\n\nresolveConflict\nAdvice shown by various commands when conflicts prevent the operation from being\nperformed.\n\nsequencerInUse\nAdvice shown when a sequencer command is already in progress.\n\nimplicitIdentity\nAdvice on how to set your identity configuration when your information is guessed\nfrom the system username and domain name.\n\ndetachedHead\nAdvice shown when you used git-switch(1) or git-checkout(1) to move to the detach\nHEAD state, to instruct how to create a local branch after the fact.\n\ncheckoutAmbiguousRemoteBranchName\nAdvice shown when the argument to git-checkout(1) and git-switch(1) ambiguously\nresolves to a remote tracking branch on more than one remote in situations where an\nunambiguous argument would have otherwise caused a remote-tracking branch to be\nchecked out. See the checkout.defaultRemote configuration variable for how to set a\ngiven remote to used by default in some situations where this advice would be\nprinted.\n\namWorkDir\nAdvice that shows the location of the patch file when git-am(1) fails to apply it.\n\nrmHints\nIn case of failure in the output of git-rm(1), show directions on how to proceed from\nthe current state.\n\naddEmbeddedRepo\nAdvice on what to do when you’ve accidentally added one git repo inside of another.\n\nignoredHook\nAdvice shown if a hook is ignored because the hook is not set as executable.\n\nwaitingForEditor\nPrint a message to the terminal whenever Git is waiting for editor input from the\nuser.\n\nnestedTag\nAdvice shown if a user attempts to recursively tag a tag object.\n\nsubmoduleAlternateErrorStrategyDie\nAdvice shown when a submodule.alternateErrorStrategy option configured to \"die\"\ncauses a fatal error.\n\naddIgnoredFile\nAdvice shown if a user attempts to add an ignored file to the index.\n\naddEmptyPathspec\nAdvice shown if a user runs the add command without providing the pathspec parameter.\n\nupdateSparsePath\nAdvice shown when either git-add(1) or git-rm(1) is asked to update index entries\noutside the current sparse checkout.\n\ncore.fileMode\nTells Git if the executable bit of files in the working tree is to be honored.\n\nSome filesystems lose the executable bit when a file that is marked as executable is\nchecked out, or checks out a non-executable file with executable bit on. git-clone(1) or\ngit-init(1) probe the filesystem to see if it handles the executable bit correctly and\nthis variable is automatically set as necessary.\n\nA repository, however, may be on a filesystem that handles the filemode correctly, and\nthis variable is set to true when created, but later may be made accessible from another\nenvironment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a\nCygwin created repository with Git for Windows or Eclipse). In such a case it may be\nnecessary to set this variable to false. See git-update-index(1).\n\nThe default is true (when core.filemode is not specified in the config file).\n\ncore.hideDotFiles\n(Windows-only) If true, mark newly-created directories and files whose name starts with a\ndot as hidden. If dotGitOnly, only the .git/ directory is hidden, but no other files\nstarting with a dot. The default mode is dotGitOnly.\n\ncore.ignoreCase\nInternal variable which enables various workarounds to enable Git to work better on\nfilesystems that are not case sensitive, like APFS, HFS+, FAT, NTFS, etc. For example, if\na directory listing finds \"makefile\" when Git expects \"Makefile\", Git will assume it is\nreally the same file, and continue to remember it as \"Makefile\".\n\nThe default is false, except git-clone(1) or git-init(1) will probe and set\ncore.ignoreCase true if appropriate when the repository is created.\n\nGit relies on the proper configuration of this variable for your operating and file\nsystem. Modifying this value may result in unexpected behavior.\n\ncore.precomposeUnicode\nThis option is only used by Mac OS implementation of Git. When\ncore.precomposeUnicode=true, Git reverts the unicode decomposition of filenames done by\nMac OS. This is useful when sharing a repository between Mac OS and Linux or Windows.\n(Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). When false, file\nnames are handled fully transparent by Git, which is backward compatible with older\nversions of Git.\n\ncore.protectHFS\nIf set to true, do not allow checkout of paths that would be considered equivalent to\n.git on an HFS+ filesystem. Defaults to true on Mac OS, and false elsewhere.\n\ncore.protectNTFS\nIf set to true, do not allow checkout of paths that would cause problems with the NTFS\nfilesystem, e.g. conflict with 8.3 \"short\" names. Defaults to true on Windows, and false\nelsewhere.\n\ncore.fsmonitor\nIf set, the value of this variable is used as a command which will identify all files\nthat may have changed since the requested date/time. This information is used to speed up\ngit by avoiding unnecessary processing of files that have not changed. See the\n\"fsmonitor-watchman\" section of githooks(5).\n\ncore.fsmonitorHookVersion\nSets the version of hook that is to be used when calling fsmonitor. There are currently\nversions 1 and 2. When this is not set, version 2 will be tried first and if it fails\nthen version 1 will be tried. Version 1 uses a timestamp as input to determine which\nfiles have changes since that time but some monitors like watchman have race conditions\nwhen used with a timestamp. Version 2 uses an opaque string so that the monitor can\nreturn something that can be used to determine what files have changed without race\nconditions.\n\ncore.trustctime\nIf false, the ctime differences between the index and the working tree are ignored;\nuseful when the inode change time is regularly modified by something outside Git (file\nsystem crawlers and some backup systems). See git-update-index(1). True by default.\n\ncore.splitIndex\nIf true, the split-index feature of the index will be used. See git-update-index(1).\nFalse by default.\n\ncore.untrackedCache\nDetermines what to do about the untracked cache feature of the index. It will be kept, if\nthis variable is unset or set to keep. It will automatically be added if set to true. And\nit will automatically be removed, if set to false. Before setting it to true, you should\ncheck that mtime is working properly on your system. See git-update-index(1). keep by\ndefault, unless feature.manyFiles is enabled which sets this setting to true by default.\n\ncore.checkStat\nWhen missing or is set to default, many fields in the stat structure are checked to\ndetect if a file has been modified since Git looked at it. When this configuration\nvariable is set to minimal, sub-second part of mtime and ctime, the uid and gid of the\nowner of the file, the inode number (and the device number, if Git was compiled to use\nit), are excluded from the check among these fields, leaving only the whole-second part\nof mtime (and ctime, if core.trustCtime is set) and the filesize to be checked.\n\nThere are implementations of Git that do not leave usable values in some fields (e.g.\nJGit); by excluding these fields from the comparison, the minimal mode may help\ninteroperability when the same repository is used by these other systems at the same\ntime.\n\ncore.quotePath\nCommands that output paths (e.g. ls-files, diff), will quote \"unusual\" characters in the\npathname by enclosing the pathname in double-quotes and escaping those characters with\nbackslashes in the same way C escapes control characters (e.g. \\t for TAB, \\n for LF, \\\\\nfor backslash) or bytes with values larger than 0x80 (e.g. octal \\302\\265 for \"micro\" in\nUTF-8). If this variable is set to false, bytes higher than 0x80 are not considered\n\"unusual\" any more. Double-quotes, backslash and control characters are always escaped\nregardless of the setting of this variable. A simple space character is not considered\n\"unusual\". Many commands can output pathnames completely verbatim using the -z option.\nThe default value is true.\n\ncore.eol\nSets the line ending type to use in the working directory for files that are marked as\ntext (either by having the text attribute set, or by having text=auto and Git\nauto-detecting the contents as text). Alternatives are lf, crlf and native, which uses\nthe platform’s native line ending. The default value is native. See gitattributes(5) for\nmore information on end-of-line conversion. Note that this value is ignored if\ncore.autocrlf is set to true or input.\n\ncore.safecrlf\nIf true, makes Git check if converting CRLF is reversible when end-of-line conversion is\nactive. Git will verify if a command modifies a file in the work tree either directly or\nindirectly. For example, committing a file followed by checking out the same file should\nyield the original file in the work tree. If this is not the case for the current setting\nof core.autocrlf, Git will reject the file. The variable can be set to \"warn\", in which\ncase Git will only warn about an irreversible conversion but continue the operation.\n\nCRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will\nconvert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a\nmixture of LF and CRLF before the commit cannot be recreated by Git. For text files this\nis the right thing to do: it corrects line endings such that we have only LF line endings\nin the repository. But for binary files that are accidentally classified as text the\nconversion can corrupt data.\n\nIf you recognize such corruption early you can easily fix it by setting the conversion\ntype explicitly in .gitattributes. Right after committing you still have the original\nfile in your work tree and this file is not yet corrupted. You can explicitly tell Git\nthat this file is binary and Git will handle the file appropriately.\n\nUnfortunately, the desired effect of cleaning up text files with mixed line endings and\nthe undesired effect of corrupting binary files cannot be distinguished. In both cases\nCRLFs are removed in an irreversible way. For text files this is the right thing to do\nbecause CRLFs are line endings, while for binary files converting CRLFs corrupts data.\n\nNote, this safety check does not mean that a checkout will generate a file identical to\nthe original file for a different setting of core.eol and core.autocrlf, but only for the\ncurrent one. For example, a text file with LF would be accepted with core.eol=lf and\ncould later be checked out with core.eol=crlf, in which case the resulting file would\ncontain CRLF, although the original file contained LF. However, in both work trees the\nline endings would be consistent, that is either all LF or all CRLF, but never mixed. A\nfile with mixed line endings would be reported by the core.safecrlf mechanism.\n\ncore.autocrlf\nSetting this variable to \"true\" is the same as setting the text attribute to \"auto\" on\nall files and core.eol to \"crlf\". Set to true if you want to have CRLF line endings in\nyour working directory and the repository has LF line endings. This variable can be set\nto input, in which case no output conversion is performed.\n\ncore.checkRoundtripEncoding\nA comma and/or whitespace separated list of encodings that Git performs UTF-8 round trip\nchecks on if they are used in an working-tree-encoding attribute (see gitattributes(5)).\nThe default value is SHIFT-JIS.\n\ncore.symlinks\nIf false, symbolic links are checked out as small plain files that contain the link text.\ngit-update-index(1) and git-add(1) will not change the recorded type to regular file.\nUseful on filesystems like FAT that do not support symbolic links.\n\nThe default is true, except git-clone(1) or git-init(1) will probe and set core.symlinks\nfalse if appropriate when the repository is created.\n\ncore.gitProxy\nA \"proxy command\" to execute (as command host port) instead of establishing direct\nconnection to the remote server when using the Git protocol for fetching. If the variable\nvalue is in the \"COMMAND for DOMAIN\" format, the command is applied only on hostnames\nending with the specified domain string. This variable may be set multiple times and is\nmatched in the given order; the first match wins.\n\nCan be overridden by the GITPROXYCOMMAND environment variable (which always applies\nuniversally, without the special \"for\" handling).\n\nThe special string none can be used as the proxy command to specify that no proxy be used\nfor a given domain pattern. This is useful for excluding servers inside a firewall from\nproxy use, while defaulting to a common proxy for external domains.\n\ncore.sshCommand\nIf this variable is set, git fetch and git push will use the specified command instead of\nssh when they need to connect to a remote system. The command is in the same form as the\nGITSSHCOMMAND environment variable and is overridden when the environment variable is\nset.\n\ncore.ignoreStat\nIf true, Git will avoid using lstat() calls to detect if files have changed by setting\nthe \"assume-unchanged\" bit for those tracked files which it has updated identically in\nboth the index and working tree.\n\nWhen files are modified outside of Git, the user will need to stage the modified files\nexplicitly (e.g. see Examples section in git-update-index(1)). Git will not normally\ndetect changes to those files.\n\nThis is useful on systems where lstat() calls are very slow, such as CIFS/Microsoft\nWindows.\n\nFalse by default.\n\ncore.preferSymlinkRefs\nInstead of the default \"symref\" format for HEAD and other symbolic reference files, use\nsymbolic links. This is sometimes needed to work with old scripts that expect HEAD to be\na symbolic link.\n\ncore.alternateRefsCommand\nWhen advertising tips of available history from an alternate, use the shell to execute\nthe specified command instead of git-for-each-ref(1). The first argument is the absolute\npath of the alternate. Output must contain one hex object id per line (i.e., the same as\nproduced by git for-each-ref --format='%(objectname)').\n\nNote that you cannot generally put git for-each-ref directly into the config value, as it\ndoes not take a repository path as an argument (but you can wrap the command above in a\nshell script).\n\ncore.alternateRefsPrefixes\nWhen listing references from an alternate, list only references that begin with the given\nprefix. Prefixes match as if they were given as arguments to git-for-each-ref(1). To list\nmultiple prefixes, separate them with whitespace. If core.alternateRefsCommand is set,\nsetting core.alternateRefsPrefixes has no effect.\n\ncore.bare\nIf true this repository is assumed to be bare and has no working directory associated\nwith it. If this is the case a number of commands that require a working directory will\nbe disabled, such as git-add(1) or git-merge(1).\n\nThis setting is automatically guessed by git-clone(1) or git-init(1) when the repository\nwas created. By default a repository that ends in \"/.git\" is assumed to be not bare (bare\n= false), while all other repositories are assumed to be bare (bare = true).\n\ncore.worktree\nSet the path to the root of the working tree. If GITCOMMONDIR environment variable is\nset, core.worktree is ignored and not used for determining the root of working tree. This\ncan be overridden by the GITWORKTREE environment variable and the --work-tree\ncommand-line option. The value can be an absolute path or relative to the path to the\n.git directory, which is either specified by --git-dir or GITDIR, or automatically\ndiscovered. If --git-dir or GITDIR is specified but none of --work-tree, GITWORKTREE\nand core.worktree is specified, the current working directory is regarded as the top\nlevel of your working tree.\n\nNote that this variable is honored even when set in a configuration file in a \".git\"\nsubdirectory of a directory and its value differs from the latter directory (e.g.\n\"/path/to/.git/config\" has core.worktree set to \"/different/path\"), which is most likely\na misconfiguration. Running Git commands in the \"/path/to\" directory will still use\n\"/different/path\" as the root of the work tree and can cause confusion unless you know\nwhat you are doing (e.g. you are creating a read-only snapshot of the same index to a\nlocation different from the repository’s usual working tree).\n\ncore.logAllRefUpdates\nEnable the reflog. Updates to a ref is logged to the file \"$GITDIR/logs/\", by\nappending the new and old SHA-1, the date/time and the reason of the update, but only\nwhen the file exists. If this configuration variable is set to true, missing\n\"$GITDIR/logs/\" file is automatically created for branch heads (i.e. under\nrefs/heads/), remote refs (i.e. under refs/remotes/), note refs (i.e. under refs/notes/),\nand the symbolic ref HEAD. If it is set to always, then a missing reflog is automatically\ncreated for any ref under refs/.\n\nThis information can be used to determine what commit was the tip of a branch \"2 days\nago\".\n\nThis value is true by default in a repository that has a working directory associated\nwith it, and false by default in a bare repository.\n\ncore.repositoryFormatVersion\nInternal variable identifying the repository format and layout version.\n\ncore.sharedRepository\nWhen group (or true), the repository is made shareable between several users in a group\n(making sure all the files and objects are group-writable). When all (or world or\neverybody), the repository will be readable by all users, additionally to being\ngroup-shareable. When umask (or false), Git will use permissions reported by umask(2).\nWhen 0xxx, where 0xxx is an octal number, files in the repository will have this mode\nvalue. 0xxx will override user’s umask value (whereas the other options will only\noverride requested parts of the user’s umask value). Examples: 0660 will make the repo\nread/write-able for the owner and group, but inaccessible to others (equivalent to group\nunless umask is e.g. 0022). 0640 is a repository that is group-readable but not\ngroup-writable. See git-init(1). False by default.\n\ncore.warnAmbiguousRefs\nIf true, Git will warn you if the ref name you passed it is ambiguous and might match\nmultiple refs in the repository. True by default.\n\ncore.compression\nAn integer -1..9, indicating a default compression level. -1 is the zlib default. 0 means\nno compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If set, this\nprovides a default to other compression variables, such as core.looseCompression and\npack.compression.\n\ncore.looseCompression\nAn integer -1..9, indicating the compression level for objects that are not in a pack\nfile. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size\ntradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not set,\ndefaults to 1 (best speed).\n\ncore.packedGitWindowSize\nNumber of bytes of a pack file to map into memory in a single mapping operation. Larger\nwindow sizes may allow your system to process a smaller number of large pack files more\nquickly. Smaller window sizes will negatively affect performance due to increased calls\nto the operating system’s memory manager, but may improve performance when accessing a\nlarge number of large pack files.\n\nDefault is 1 MiB if NOMMAP was set at compile time, otherwise 32 MiB on 32 bit platforms\nand 1 GiB on 64 bit platforms. This should be reasonable for all users/operating systems.\nYou probably do not need to adjust this value.\n\nCommon unit suffixes of k, m, or g are supported.\n\ncore.packedGitLimit\nMaximum number of bytes to map simultaneously into memory from pack files. If Git needs\nto access more than this many bytes at once to complete an operation it will unmap\nexisting regions to reclaim virtual address space within the process.\n\nDefault is 256 MiB on 32 bit platforms and 32 TiB (effectively unlimited) on 64 bit\nplatforms. This should be reasonable for all users/operating systems, except on the\nlargest projects. You probably do not need to adjust this value.\n\nCommon unit suffixes of k, m, or g are supported.\n\ncore.deltaBaseCacheLimit\nMaximum number of bytes per thread to reserve for caching base objects that may be\nreferenced by multiple deltified objects. By storing the entire decompressed base objects\nin a cache Git is able to avoid unpacking and decompressing frequently used base objects\nmultiple times.\n\nDefault is 96 MiB on all platforms. This should be reasonable for all users/operating\nsystems, except on the largest projects. You probably do not need to adjust this value.\n\nCommon unit suffixes of k, m, or g are supported.\n\ncore.bigFileThreshold\nFiles larger than this size are stored deflated, without attempting delta compression.\nStoring large files without delta compression avoids excessive memory usage, at the\nslight expense of increased disk usage. Additionally files larger than this size are\nalways treated as binary.\n\nDefault is 512 MiB on all platforms. This should be reasonable for most projects as\nsource code and other text files can still be delta compressed, but larger binary media\nfiles won’t be.\n\nCommon unit suffixes of k, m, or g are supported.\n\ncore.excludesFile\nSpecifies the pathname to the file that contains patterns to describe paths that are not\nmeant to be tracked, in addition to .gitignore (per-directory) and .git/info/exclude.\nDefaults to $XDGCONFIGHOME/git/ignore. If $XDGCONFIGHOME is either not set or empty,\n$HOME/.config/git/ignore is used instead. See gitignore(5).\n\ncore.askPass\nSome commands (e.g. svn and http interfaces) that interactively ask for a password can be\ntold to use an external program given via the value of this variable. Can be overridden\nby the GITASKPASS environment variable. If not set, fall back to the value of the\nSSHASKPASS environment variable or, failing that, a simple password prompt. The external\nprogram shall be given a suitable prompt as command-line argument and write the password\non its STDOUT.\n\ncore.attributesFile\nIn addition to .gitattributes (per-directory) and .git/info/attributes, Git looks into\nthis file for attributes (see gitattributes(5)). Path expansions are made the same way as\nfor core.excludesFile. Its default value is $XDGCONFIGHOME/git/attributes. If\n$XDGCONFIGHOME is either not set or empty, $HOME/.config/git/attributes is used\ninstead.\n\ncore.hooksPath\nBy default Git will look for your hooks in the $GITDIR/hooks directory. Set this to\ndifferent path, e.g. /etc/git/hooks, and Git will try to find your hooks in that\ndirectory, e.g. /etc/git/hooks/pre-receive instead of in $GITDIR/hooks/pre-receive.\n\nThe path can be either absolute or relative. A relative path is taken as relative to the\ndirectory where the hooks are run (see the \"DESCRIPTION\" section of githooks(5)).\n\nThis configuration variable is useful in cases where you’d like to centrally configure\nyour Git hooks instead of configuring them on a per-repository basis, or as a more\nflexible and centralized alternative to having an init.templateDir where you’ve changed\ndefault hooks.\n\ncore.editor\nCommands such as commit and tag that let you edit messages by launching an editor use the\nvalue of this variable when it is set, and the environment variable GITEDITOR is not\nset. See git-var(1).\n\ncore.commentChar\nCommands such as commit and tag that let you edit messages consider a line that begins\nwith this character commented, and removes them after the editor returns (default #).\n\nIf set to \"auto\", git-commit would select a character that is not the beginning character\nof any line in existing commit messages.\n\ncore.filesRefLockTimeout\nThe length of time, in milliseconds, to retry when trying to lock an individual\nreference. Value 0 means not to retry at all; -1 means to try indefinitely. Default is\n100 (i.e., retry for 100ms).\n\ncore.packedRefsTimeout\nThe length of time, in milliseconds, to retry when trying to lock the packed-refs file.\nValue 0 means not to retry at all; -1 means to try indefinitely. Default is 1000 (i.e.,\nretry for 1 second).\n\ncore.pager\nText viewer for use by Git commands (e.g., less). The value is meant to be interpreted by\nthe shell. The order of preference is the $GITPAGER environment variable, then\ncore.pager configuration, then $PAGER, and then the default chosen at compile time\n(usually less).\n\nWhen the LESS environment variable is unset, Git sets it to FRX (if LESS environment\nvariable is set, Git does not change it at all). If you want to selectively override\nGit’s default setting for LESS, you can set core.pager to e.g. less -S. This will be\npassed to the shell by Git, which will translate the final command to LESS=FRX less -S.\nThe environment does not set the S option but the command line does, instructing less to\ntruncate long lines. Similarly, setting core.pager to less -+F will deactivate the F\noption specified by the environment from the command-line, deactivating the \"quit if one\nscreen\" behavior of less. One can specifically activate some flags for particular\ncommands: for example, setting pager.blame to less -S enables line truncation only for\ngit blame.\n\nLikewise, when the LV environment variable is unset, Git sets it to -c. You can override\nthis setting by exporting LV with another value or setting core.pager to lv +c.\n\ncore.whitespace\nA comma separated list of common whitespace problems to notice. git diff will use\ncolor.diff.whitespace to highlight them, and git apply --whitespace=error will consider\nthem as errors. You can prefix - to disable any of them (e.g. -trailing-space):\n\n• blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled\nby default).\n\n• space-before-tab treats a space character that appears immediately before a tab\ncharacter in the initial indent part of the line as an error (enabled by default).\n\n• indent-with-non-tab treats a line that is indented with space characters instead of\nthe equivalent tabs as an error (not enabled by default).\n\n• tab-in-indent treats a tab character in the initial indent part of the line as an\nerror (not enabled by default).\n\n• blank-at-eof treats blank lines added at the end of file as an error (enabled by\ndefault).\n\n• trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.\n\n• cr-at-eol treats a carriage-return at the end of line as part of the line terminator,\ni.e. with it, trailing-space does not trigger if the character before such a\ncarriage-return is not a whitespace (not enabled by default).\n\n• tabwidth= tells how many character positions a tab occupies; this is relevant for\nindent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is\n8. Allowed values are 1 to 63.\n\ncore.fsyncObjectFiles\nThis boolean will enable fsync() when writing object files.\n\nThis is a total waste of time and effort on a filesystem that orders data writes\nproperly, but can be useful for filesystems that do not use journalling (traditional UNIX\nfilesystems) or that only journal metadata and not file contents (OS X’s HFS+, or Linux\next3 with \"data=writeback\").\n\ncore.preloadIndex\nEnable parallel index preload for operations like git diff\n\nThis can speed up operations like git diff and git status especially on filesystems like\nNFS that have weak caching semantics and thus relatively high IO latencies. When enabled,\nGit will do the index comparison to the filesystem data in parallel, allowing overlapping\nIO’s. Defaults to true.\n\ncore.unsetenvvars\nWindows-only: comma-separated list of environment variables' names that need to be unset\nbefore spawning any other process. Defaults to PERL5LIB to account for the fact that Git\nfor Windows insists on using its own Perl interpreter.\n\ncore.restrictinheritedhandles\nWindows-only: override whether spawned processes inherit only standard file handles\n(stdin, stdout and stderr) or all handles. Can be auto, true or false. Defaults to auto,\nwhich means true on Windows 7 and later, and false on older Windows versions.\n\ncore.createObject\nYou can set this to link, in which case a hardlink followed by a delete of the source are\nused to make sure that object creation will not overwrite existing objects.\n\nOn some file system/operating system combinations, this is unreliable. Set this config\nsetting to rename there; However, This will remove the check that makes sure that\nexisting object files will not get overwritten.\n\ncore.notesRef\nWhen showing commit messages, also show notes which are stored in the given ref. The ref\nmust be fully qualified. If the given ref does not exist, it is not an error but means\nthat no notes should be printed.\n\nThis setting defaults to \"refs/notes/commits\", and it can be overridden by the\nGITNOTESREF environment variable. See git-notes(1).\n\ncore.commitGraph\nIf true, then git will read the commit-graph file (if it exists) to parse the graph\nstructure of commits. Defaults to true. See git-commit-graph(1) for more information.\n\ncore.useReplaceRefs\nIf set to false, behave as if the --no-replace-objects option was given on the command\nline. See git(1) and git-replace(1) for more information.\n\ncore.multiPackIndex\nUse the multi-pack-index file to track multiple packfiles using a single index. See git-\nmulti-pack-index(1) for more information. Defaults to true.\n\ncore.sparseCheckout\nEnable \"sparse checkout\" feature. See git-sparse-checkout(1) for more information.\n\ncore.sparseCheckoutCone\nEnables the \"cone mode\" of the sparse checkout feature. When the sparse-checkout file\ncontains a limited set of patterns, then this mode provides significant performance\nadvantages. See git-sparse-checkout(1) for more information.\n\ncore.abbrev\nSet the length object names are abbreviated to. If unspecified or set to \"auto\", an\nappropriate value is computed based on the approximate number of packed objects in your\nrepository, which hopefully is enough for abbreviated object names to stay unique for\nsome time. If set to \"no\", no abbreviation is made and the object names are shown in\ntheir full length. The minimum length is 4.\n\nadd.ignoreErrors, add.ignore-errors (deprecated)\nTells git add to continue adding files when some files cannot be added due to indexing\nerrors. Equivalent to the --ignore-errors option of git-add(1). add.ignore-errors is\ndeprecated, as it does not follow the usual naming convention for configuration\nvariables.\n\nadd.interactive.useBuiltin\n[EXPERIMENTAL] Set to true to use the experimental built-in implementation of the\ninteractive version of git-add(1) instead of the Perl script version. Is false by\ndefault.\n\nalias.*\nCommand aliases for the git(1) command wrapper - e.g. after defining alias.last =\ncat-file commit HEAD, the invocation git last is equivalent to git cat-file commit HEAD.\nTo avoid confusion and troubles with script usage, aliases that hide existing Git\ncommands are ignored. Arguments are split by spaces, the usual shell quoting and escaping\nis supported. A quote pair or a backslash can be used to quote them.\n\nNote that the first word of an alias does not necessarily have to be a command. It can be\na command-line option that will be passed into the invocation of git. In particular, this\nis useful when used with -c to pass in one-time configurations or -p to force pagination.\nFor example, loud-rebase = -c commit.verbose=true rebase can be defined such that running\ngit loud-rebase would be equivalent to git -c commit.verbose=true rebase. Also, ps = -p\nstatus would be a helpful alias since git ps would paginate the output of git status\nwhere the original command does not.\n\nIf the alias expansion is prefixed with an exclamation point, it will be treated as a\nshell command. For example, defining alias.new = !gitk --all --not ORIGHEAD, the\ninvocation git new is equivalent to running the shell command gitk --all --not ORIGHEAD.\nNote that shell commands will be executed from the top-level directory of a repository,\nwhich may not necessarily be the current directory. GITPREFIX is set as returned by\nrunning git rev-parse --show-prefix from the original current directory. See git-rev-\nparse(1).\n\nam.keepcr\nIf true, git-am will call git-mailsplit for patches in mbox format with parameter\n--keep-cr. In this case git-mailsplit will not remove \\r from lines ending with \\r\\n. Can\nbe overridden by giving --no-keep-cr from the command line. See git-am(1), git-\nmailsplit(1).\n\nam.threeWay\nBy default, git am will fail if the patch does not apply cleanly. When set to true, this\nsetting tells git am to fall back on 3-way merge if the patch records the identity of\nblobs it is supposed to apply to and we have those blobs available locally (equivalent to\ngiving the --3way option from the command line). Defaults to false. See git-am(1).\n\napply.ignoreWhitespace\nWhen set to change, tells git apply to ignore changes in whitespace, in the same way as\nthe --ignore-space-change option. When set to one of: no, none, never, false tells git\napply to respect all whitespace differences. See git-apply(1).\n\napply.whitespace\nTells git apply how to handle whitespaces, in the same way as the --whitespace option.\nSee git-apply(1).\n\nblame.blankBoundary\nShow blank commit object name for boundary commits in git-blame(1). This option defaults\nto false.\n\nblame.coloring\nThis determines the coloring scheme to be applied to blame output. It can be\nrepeatedLines, highlightRecent, or none which is the default.\n\nblame.date\nSpecifies the format used to output dates in git-blame(1). If unset the iso format is\nused. For supported values, see the discussion of the --date option at git-log(1).\n\nblame.showEmail\nShow the author email instead of author name in git-blame(1). This option defaults to\nfalse.\n\nblame.showRoot\nDo not treat root commits as boundaries in git-blame(1). This option defaults to false.\n\nblame.ignoreRevsFile\nIgnore revisions listed in the file, one unabbreviated object name per line, in git-\nblame(1). Whitespace and comments beginning with # are ignored. This option may be\nrepeated multiple times. Empty file names will reset the list of ignored revisions. This\noption will be handled before the command line option --ignore-revs-file.\n\nblame.markUnblamableLines\nMark lines that were changed by an ignored revision that we could not attribute to\nanother commit with a * in the output of git-blame(1).\n\nblame.markIgnoredLines\nMark lines that were changed by an ignored revision that we attributed to another commit\nwith a ? in the output of git-blame(1).\n\nbranch.autoSetupMerge\nTells git branch, git switch and git checkout to set up new branches so that git-pull(1)\nwill appropriately merge from the starting point branch. Note that even if this option is\nnot set, this behavior can be chosen per-branch using the --track and --no-track options.\nThe valid settings are: false — no automatic setup is done; true — automatic setup is\ndone when the starting point is a remote-tracking branch; always — automatic setup is\ndone when the starting point is either a local branch or remote-tracking branch. This\noption defaults to true.\n\nbranch.autoSetupRebase\nWhen a new branch is created with git branch, git switch or git checkout that tracks\nanother branch, this variable tells Git to set up pull to rebase instead of merge (see\n\"branch..rebase\"). When never, rebase is never automatically set to true. When\nlocal, rebase is set to true for tracked branches of other local branches. When remote,\nrebase is set to true for tracked branches of remote-tracking branches. When always,\nrebase will be set to true for all tracking branches. See \"branch.autoSetupMerge\" for\ndetails on how to set up a branch to track another branch. This option defaults to never.\n\nbranch.sort\nThis variable controls the sort ordering of branches when displayed by git-branch(1).\nWithout the \"--sort=\" option provided, the value of this variable will be used as\nthe default. See git-for-each-ref(1) field names for valid values.\n\nbranch..remote\nWhen on branch , it tells git fetch and git push which remote to fetch from/push\nto. The remote to push to may be overridden with remote.pushDefault (for all branches).\nThe remote to push to, for the current branch, may be further overridden by\nbranch..pushRemote. If no remote is configured, or if you are not on any branch, it\ndefaults to origin for fetching and remote.pushDefault for pushing. Additionally, . (a\nperiod) is the current local repository (a dot-repository), see branch..merge's\nfinal note below.\n\nbranch..pushRemote\nWhen on branch , it overrides branch..remote for pushing. It also overrides\nremote.pushDefault for pushing from branch . When you pull from one place (e.g.\nyour upstream) and push to another place (e.g. your own publishing repository), you would\nwant to set remote.pushDefault to specify the remote to push to for all branches, and use\nthis option to override it for a specific branch.\n\nbranch..merge\nDefines, together with branch..remote, the upstream branch for the given branch. It\ntells git fetch/git pull/git rebase which branch to merge and can also affect git push\n(see push.default). When in branch , it tells git fetch the default refspec to be\nmarked for merging in FETCHHEAD. The value is handled like the remote part of a refspec,\nand must match a ref which is fetched from the remote given by \"branch..remote\".\nThe merge information is used by git pull (which at first calls git fetch) to lookup the\ndefault branch for merging. Without this option, git pull defaults to merge the first\nrefspec fetched. Specify multiple values to get an octopus merge. If you wish to setup\ngit pull so that it merges into from another branch in the local repository, you\ncan point branch..merge to the desired branch, and use the relative path setting .\n(a period) for branch..remote.\n\nbranch..mergeOptions\nSets default options for merging into branch . The syntax and supported options are\nthe same as those of git-merge(1), but option values containing whitespace characters are\ncurrently not supported.\n\nbranch..rebase\nWhen true, rebase the branch on top of the fetched branch, instead of merging the\ndefault branch from the default remote when \"git pull\" is run. See \"pull.rebase\" for\ndoing this in a non branch-specific manner.\n\nWhen merges (or just m), pass the --rebase-merges option to git rebase so that the local\nmerge commits are included in the rebase (see git-rebase(1) for details).\n\nWhen the value is interactive (or just i), the rebase is run in interactive mode.\n\nNOTE: this is a possibly dangerous operation; do not use it unless you understand the\nimplications (see git-rebase(1) for details).\n\nbranch..description\nBranch description, can be edited with git branch --edit-description. Branch description\nis automatically added in the format-patch cover letter or request-pull summary.\n\nbrowser..cmd\nSpecify the command to invoke the specified browser. The specified command is evaluated\nin shell with the URLs passed as arguments. (See git-web--browse(1).)\n\nbrowser..path\nOverride the path for the given tool that may be used to browse HTML help (see -w option\nin git-help(1)) or a working repository in gitweb (see git-instaweb(1)).\n\ncheckout.defaultRemote\nWhen you run git checkout or git switch and only have one remote,\nit may implicitly fall back on checking out and tracking e.g. origin/. This\nstops working as soon as you have more than one remote with a reference. This\nsetting allows for setting the name of a preferred remote that should always win when it\ncomes to disambiguation. The typical use-case is to set this to origin.\n\nCurrently this is used by git-switch(1) and git-checkout(1) when git checkout \nor git switch will checkout the branch on another remote, and by\ngit-worktree(1) when git worktree add refers to a remote branch. This setting might be\nused for other checkout-like commands or functionality in the future.\n\ncheckout.guess\nProvides the default value for the --guess or --no-guess option in git checkout and git\nswitch. See git-switch(1) and git-checkout(1).\n\ncheckout.workers\nThe number of parallel workers to use when updating the working tree. The default is one,\ni.e. sequential execution. If set to a value less than one, Git will use as many workers\nas the number of logical cores available. This setting and\ncheckout.thresholdForParallelism affect all commands that perform checkout. E.g.\ncheckout, clone, reset, sparse-checkout, etc.\n\nNote: parallel checkout usually delivers better performance for repositories located on\nSSDs or over NFS. For repositories on spinning disks and/or machines with a small number\nof cores, the default sequential checkout often performs better. The size and compression\nlevel of a repository might also influence how well the parallel version performs.\n\ncheckout.thresholdForParallelism\nWhen running parallel checkout with a small number of files, the cost of subprocess\nspawning and inter-process communication might outweigh the parallelization gains. This\nsetting allows to define the minimum number of files for which parallel checkout should\nbe attempted. The default is 100.\n\nclean.requireForce\nA boolean to make git-clean do nothing unless given -f, -i or -n. Defaults to true.\n\nclone.defaultRemoteName\nThe name of the remote to create when cloning a repository. Defaults to origin, and can\nbe overridden by passing the --origin command-line option to git-clone(1).\n\nclone.rejectShallow\nReject to clone a repository if it is a shallow one, can be overridden by passing option\n--reject-shallow in command line. See git-clone(1)\n\ncolor.advice\nA boolean to enable/disable color in hints (e.g. when a push failed, see advice.* for a\nlist). May be set to always, false (or never) or auto (or true), in which case colors are\nused only when the error output goes to a terminal. If unset, then the value of color.ui\nis used (auto by default).\n\ncolor.advice.hint\nUse customized color for hints.\n\ncolor.blame.highlightRecent\nSpecify the line annotation color for git blame --color-by-age depending upon the age of\nthe line.\n\nThis setting should be set to a comma-separated list of color and date settings, starting\nand ending with a color, the dates should be set from oldest to newest. The metadata will\nbe colored with the specified colors if the line was introduced before the given\ntimestamp, overwriting older timestamped colors.\n\nInstead of an absolute timestamp relative timestamps work as well, e.g. 2.weeks.ago is\nvalid to address anything older than 2 weeks.\n\nIt defaults to blue,12 month ago,white,1 month ago,red, which colors everything older\nthan one year blue, recent changes between one month and one year old are kept white, and\nlines introduced within the last month are colored red.\n\ncolor.blame.repeatedLines\nUse the specified color to colorize line annotations for git blame --color-lines, if they\ncome from the same commit as the preceding line. Defaults to cyan.\n\ncolor.branch\nA boolean to enable/disable color in the output of git-branch(1). May be set to always,\nfalse (or never) or auto (or true), in which case colors are used only when the output is\nto a terminal. If unset, then the value of color.ui is used (auto by default).\n\ncolor.branch.\nUse customized color for branch coloration. is one of current (the current\nbranch), local (a local branch), remote (a remote-tracking branch in refs/remotes/),\nupstream (upstream tracking branch), plain (other refs).\n\ncolor.diff\nWhether to use ANSI escape sequences to add color to patches. If this is set to always,\ngit-diff(1), git-log(1), and git-show(1) will use color for all patches. If it is set to\ntrue or auto, those commands will only use color when output is to the terminal. If\nunset, then the value of color.ui is used (auto by default).\n\nThis does not affect git-format-patch(1) or the git-diff-* plumbing commands. Can be\noverridden on the command line with the --color[=] option.\n\ncolor.diff.\nUse customized color for diff colorization. specifies which part of the patch to\nuse the specified color, and is one of context (context text - plain is a historical\nsynonym), meta (metainformation), frag (hunk header), func (function in hunk header), old\n(removed lines), new (added lines), commit (commit headers), whitespace (highlighting\nwhitespace errors), oldMoved (deleted lines), newMoved (added lines), oldMovedDimmed,\noldMovedAlternative, oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative\nnewMovedAlternativeDimmed (See the setting of --color-moved in git-diff(1) for\ndetails), contextDimmed, oldDimmed, newDimmed, contextBold, oldBold, and newBold (see\ngit-range-diff(1) for details).\n\ncolor.decorate.\nUse customized color for git log --decorate output. is one of branch,\nremoteBranch, tag, stash or HEAD for local branches, remote-tracking branches, tags,\nstash and HEAD, respectively and grafted for grafted commits.\n\ncolor.grep\nWhen set to always, always highlight matches. When false (or never), never. When set to\ntrue or auto, use color only when the output is written to the terminal. If unset, then\nthe value of color.ui is used (auto by default).\n\ncolor.grep.\nUse customized color for grep colorization. specifies which part of the line to\nuse the specified color, and is one of\n\ncontext\nnon-matching text in context lines (when using -A, -B, or -C)\n\nfilename\nfilename prefix (when not using -h)\n\nfunction\nfunction name lines (when using -p)\n\nlineNumber\nline number prefix (when using -n)\n\ncolumn\ncolumn number prefix (when using --column)\n\nmatch\nmatching text (same as setting matchContext and matchSelected)\n\nmatchContext\nmatching text in context lines\n\nmatchSelected\nmatching text in selected lines. Also, used to customize the following git-log(1)\nsubcommands: --grep, --author and --committer.\n\nselected\nnon-matching text in selected lines. Also, used to customize the following git-log(1)\nsubcommands: --grep, --author and --committer.\n\nseparator\nseparators between fields on a line (:, -, and =) and between hunks (--)\n\ncolor.interactive\nWhen set to always, always use colors for interactive prompts and displays (such as those\nused by \"git-add --interactive\" and \"git-clean --interactive\"). When false (or never),\nnever. When set to true or auto, use colors only when the output is to the terminal. If\nunset, then the value of color.ui is used (auto by default).\n\ncolor.interactive.\nUse customized color for git add --interactive and git clean --interactive output.\n may be prompt, header, help or error, for four distinct types of normal output\nfrom interactive commands.\n\ncolor.pager\nA boolean to specify whether auto color modes should colorize output going to the pager.\nDefaults to true; set this to false if your pager does not understand ANSI color codes.\n\ncolor.push\nA boolean to enable/disable color in push errors. May be set to always, false (or never)\nor auto (or true), in which case colors are used only when the error output goes to a\nterminal. If unset, then the value of color.ui is used (auto by default).\n\ncolor.push.error\nUse customized color for push errors.\n\ncolor.remote\nIf set, keywords at the start of the line are highlighted. The keywords are \"error\",\n\"warning\", \"hint\" and \"success\", and are matched case-insensitively. May be set to\nalways, false (or never) or auto (or true). If unset, then the value of color.ui is used\n(auto by default).\n\ncolor.remote.\nUse customized color for each remote keyword. may be hint, warning, success or\nerror which match the corresponding keyword.\n\ncolor.showBranch\nA boolean to enable/disable color in the output of git-show-branch(1). May be set to\nalways, false (or never) or auto (or true), in which case colors are used only when the\noutput is to a terminal. If unset, then the value of color.ui is used (auto by default).\n\ncolor.status\nA boolean to enable/disable color in the output of git-status(1). May be set to always,\nfalse (or never) or auto (or true), in which case colors are used only when the output is\nto a terminal. If unset, then the value of color.ui is used (auto by default).\n\ncolor.status.\nUse customized color for status colorization. is one of header (the header text\nof the status message), added or updated (files which are added but not committed),\nchanged (files which are changed but not added in the index), untracked (files which are\nnot tracked by Git), branch (the current branch), nobranch (the color the no branch\nwarning is shown in, defaulting to red), localBranch or remoteBranch (the local and\nremote branch names, respectively, when branch and tracking information is displayed in\nthe status short-format), or unmerged (files which have unmerged changes).\n\ncolor.transport\nA boolean to enable/disable color when pushes are rejected. May be set to always, false\n(or never) or auto (or true), in which case colors are used only when the error output\ngoes to a terminal. If unset, then the value of color.ui is used (auto by default).\n\ncolor.transport.rejected\nUse customized color when a push was rejected.\n\ncolor.ui\nThis variable determines the default value for variables such as color.diff and\ncolor.grep that control the use of color per command family. Its scope will expand as\nmore commands learn configuration to set a default for the --color option. Set it to\nfalse or never if you prefer Git commands not to use color unless enabled explicitly with\nsome other configuration or the --color option. Set it to always if you want all output\nnot intended for machine consumption to use color, to true or auto (this is the default\nsince Git 1.8.4) if you want such output to use color when written to the terminal.\n\ncolumn.ui\nSpecify whether supported commands should output in columns. This variable consists of a\nlist of tokens separated by spaces or commas:\n\nThese options control when the feature should be enabled (defaults to never):\n\nalways\nalways show in columns\n\nnever\nnever show in columns\n\nauto\nshow in columns if the output is to the terminal\n\nThese options control layout (defaults to column). Setting any of these implies always if\nnone of always, never, or auto are specified.\n\ncolumn\nfill columns before rows\n\nrow\nfill rows before columns\n\nplain\nshow in one column\n\nFinally, these options can be combined with a layout option (defaults to nodense):\n\ndense\nmake unequal size columns to utilize more space\n\nnodense\nmake equal size columns\n\ncolumn.branch\nSpecify whether to output branch listing in git branch in columns. See column.ui for\ndetails.\n\ncolumn.clean\nSpecify the layout when list items in git clean -i, which always shows files and\ndirectories in columns. See column.ui for details.\n\ncolumn.status\nSpecify whether to output untracked files in git status in columns. See column.ui for\ndetails.\n\ncolumn.tag\nSpecify whether to output tag listing in git tag in columns. See column.ui for details.\n\ncommit.cleanup\nThis setting overrides the default of the --cleanup option in git commit. See git-\ncommit(1) for details. Changing the default can be useful when you always want to keep\nlines that begin with comment character # in your log message, in which case you would do\ngit config commit.cleanup whitespace (note that you will have to remove the help lines\nthat begin with # in the commit log template yourself, if you do this).\n\ncommit.gpgSign\nA boolean to specify whether all commits should be GPG signed. Use of this option when\ndoing operations such as rebase can result in a large number of commits being signed. It\nmay be convenient to use an agent to avoid typing your GPG passphrase several times.\n\ncommit.status\nA boolean to enable/disable inclusion of status information in the commit message\ntemplate when using an editor to prepare the commit message. Defaults to true.\n\ncommit.template\nSpecify the pathname of a file to use as the template for new commit messages.\n\ncommit.verbose\nA boolean or int to specify the level of verbose with git commit. See git-commit(1).\n\ncommitGraph.generationVersion\nSpecifies the type of generation number version to use when writing or reading the\ncommit-graph file. If version 1 is specified, then the corrected commit dates will not be\nwritten or read. Defaults to 2.\n\ncommitGraph.maxNewFilters\nSpecifies the default value for the --max-new-filters option of git commit-graph write\n(c.f., git-commit-graph(1)).\n\ncommitGraph.readChangedPaths\nIf true, then git will use the changed-path Bloom filters in the commit-graph file (if it\nexists, and they are present). Defaults to true. See git-commit-graph(1) for more\ninformation.\n\ncredential.helper\nSpecify an external helper to be called when a username or password credential is needed;\nthe helper may consult external storage to avoid prompting the user for the credentials.\nThis is normally the name of a credential helper with possible arguments, but may also be\nan absolute path with arguments or, if preceded by !, shell commands.\n\nNote that multiple helpers may be defined. See gitcredentials(7) for details and\nexamples.\n\ncredential.useHttpPath\nWhen acquiring credentials, consider the \"path\" component of an http or https URL to be\nimportant. Defaults to false. See gitcredentials(7) for more information.\n\ncredential.sanitizePrompt\nBy default, user names and hosts that are shown as part of the password prompt are not\nallowed to contain control characters (they will be URL-encoded by default). Configure\nthis setting to false to override that behavior.\n\ncredential.protectProtocol\nBy default, Carriage Return characters are not allowed in the protocol that is used when\nGit talks to a credential helper. This setting allows users to override this default.\n\ncredential.username\nIf no username is set for a network authentication, use this username by default. See\ncredential..* below, and gitcredentials(7).\n\ncredential..*\nAny of the credential.* options above can be applied selectively to some credentials. For\nexample \"credential.https://example.com.username\" would set the default username only for\nhttps connections to example.com. See gitcredentials(7) for details on how URLs are\nmatched.\n\ncredentialCache.ignoreSIGHUP\nTell git-credential-cache—daemon to ignore SIGHUP, instead of quitting.\n\ncredentialStore.lockTimeoutMS\nThe length of time, in milliseconds, for git-credential-store to retry when trying to\nlock the credentials file. Value 0 means not to retry at all; -1 means to try\nindefinitely. Default is 1000 (i.e., retry for 1s).\n\ncompletion.commands\nThis is only used by git-completion.bash to add or remove commands from the list of\ncompleted commands. Normally only porcelain commands and a few select others are\ncompleted. You can add more commands, separated by space, in this variable. Prefixing the\ncommand with - will remove it from the existing list.\n\ndiff.autoRefreshIndex\nWhen using git diff to compare with work tree files, do not consider stat-only change as\nchanged. Instead, silently run git update-index --refresh to update the cached stat\ninformation for paths whose contents in the work tree match the contents in the index.\nThis option defaults to true. Note that this affects only git diff Porcelain, and not\nlower level diff commands such as git diff-files.\n\ndiff.dirstat\nA comma separated list of --dirstat parameters specifying the default behavior of the\n--dirstat option to git-diff(1) and friends. The defaults can be overridden on the\ncommand line (using --dirstat=). The fallback defaults (when not\nchanged by diff.dirstat) are changes,noncumulative,3. The following parameters are\navailable:\n\nchanges\nCompute the dirstat numbers by counting the lines that have been removed from the\nsource, or added to the destination. This ignores the amount of pure code movements\nwithin a file. In other words, rearranging lines in a file is not counted as much as\nother changes. This is the default behavior when no parameter is given.\n\nlines\nCompute the dirstat numbers by doing the regular line-based diff analysis, and\nsumming the removed/added line counts. (For binary files, count 64-byte chunks\ninstead, since binary files have no natural concept of lines). This is a more\nexpensive --dirstat behavior than the changes behavior, but it does count rearranged\nlines within a file as much as other changes. The resulting output is consistent with\nwhat you get from the other --*stat options.\n\nfiles\nCompute the dirstat numbers by counting the number of files changed. Each changed\nfile counts equally in the dirstat analysis. This is the computationally cheapest\n--dirstat behavior, since it does not have to look at the file contents at all.\n\ncumulative\nCount changes in a child directory for the parent directory as well. Note that when\nusing cumulative, the sum of the percentages reported may exceed 100%. The default\n(non-cumulative) behavior can be specified with the noncumulative parameter.\n\n\nAn integer parameter specifies a cut-off percent (3% by default). Directories\ncontributing less than this percentage of the changes are not shown in the output.\n\nExample: The following will count changed files, while ignoring directories with less\nthan 10% of the total amount of changed files, and accumulating child directory counts in\nthe parent directories: files,10,cumulative.\n\ndiff.statGraphWidth\nLimit the width of the graph part in --stat output. If set, applies to all commands\ngenerating --stat output except format-patch.\n\ndiff.context\nGenerate diffs with lines of context instead of the default of 3. This value is\noverridden by the -U option.\n\ndiff.interHunkContext\nShow the context between diff hunks, up to the specified number of lines, thereby fusing\nthe hunks that are close to each other. This value serves as the default for the\n--inter-hunk-context command line option.\n\ndiff.external\nIf this config variable is set, diff generation is not performed using the internal diff\nmachinery, but using the given command. Can be overridden with the ‘GITEXTERNALDIFF’\nenvironment variable. The command is called with parameters as described under \"git\nDiffs\" in git(1). Note: if you want to use an external diff program only on a subset of\nyour files, you might want to use gitattributes(5) instead.\n\ndiff.ignoreSubmodules\nSets the default value of --ignore-submodules. Note that this affects only git diff\nPorcelain, and not lower level diff commands such as git diff-files. git checkout and\ngit switch also honor this setting when reporting uncommitted changes. Setting it to all\ndisables the submodule summary normally shown by git commit and git status when\nstatus.submoduleSummary is set unless it is overridden by using the --ignore-submodules\ncommand-line option. The git submodule commands are not affected by this setting. By\ndefault this is set to untracked so that any untracked submodules are ignored.\n\ndiff.mnemonicPrefix\nIf set, git diff uses a prefix pair that is different from the standard \"a/\" and \"b/\"\ndepending on what is being compared. When this configuration is in effect, reverse diff\noutput also swaps the order of the prefixes:\n\ngit diff\ncompares the (i)ndex and the (w)ork tree;\n\ngit diff HEAD\ncompares a (c)ommit and the (w)ork tree;\n\ngit diff --cached\ncompares a (c)ommit and the (i)ndex;\n\ngit diff HEAD:file1 file2\ncompares an (o)bject and a (w)ork tree entity;\n\ngit diff --no-index a b\ncompares two non-git things (1) and (2).\n\ndiff.noprefix\nIf set, git diff does not show any source or destination prefix.\n\ndiff.relative\nIf set to true, git diff does not show changes outside of the directory and show\npathnames relative to the current directory.\n\ndiff.orderFile\nFile indicating how to order files within a diff. See the -O option to git-diff(1) for\ndetails. If diff.orderFile is a relative pathname, it is treated as relative to the top\nof the working tree.\n\ndiff.renameLimit\nThe number of files to consider in the exhaustive portion of copy/rename detection;\nequivalent to the git diff option -l. If not set, the default value is currently 1000.\nThis setting has no effect if rename detection is turned off.\n\ndiff.renames\nWhether and how Git detects renames. If set to \"false\", rename detection is disabled. If\nset to \"true\", basic rename detection is enabled. If set to \"copies\" or \"copy\", Git will\ndetect copies, as well. Defaults to true. Note that this affects only git diff Porcelain\nlike git-diff(1) and git-log(1), and not lower level commands such as git-diff-files(1).\n\ndiff.suppressBlankEmpty\nA boolean to inhibit the standard behavior of printing a space before each empty output\nline. Defaults to false.\n\ndiff.submodule\nSpecify the format in which differences in submodules are shown. The \"short\" format just\nshows the names of the commits at the beginning and end of the range. The \"log\" format\nlists the commits in the range like git-submodule(1) summary does. The \"diff\" format\nshows an inline diff of the changed contents of the submodule. Defaults to \"short\".\n\ndiff.wordRegex\nA POSIX Extended Regular Expression used to determine what is a \"word\" when performing\nword-by-word difference calculations. Character sequences that match the regular\nexpression are \"words\", all other characters are ignorable whitespace.\n\ndiff..command\nThe custom diff driver command. See gitattributes(5) for details.\n\ndiff..xfuncname\nThe regular expression that the diff driver should use to recognize the hunk header. A\nbuilt-in pattern may also be used. See gitattributes(5) for details.\n\ndiff..binary\nSet this option to true to make the diff driver treat files as binary. See\ngitattributes(5) for details.\n\ndiff..textconv\nThe command that the diff driver should call to generate the text-converted version of a\nfile. The result of the conversion is used to generate a human-readable diff. See\ngitattributes(5) for details.\n\ndiff..wordRegex\nThe regular expression that the diff driver should use to split words in a line. See\ngitattributes(5) for details.\n\ndiff..cachetextconv\nSet this option to true to make the diff driver cache the text conversion outputs. See\ngitattributes(5) for details.\n\ndiff.tool\nControls which diff tool is used by git-difftool(1). This variable overrides the value\nconfigured in merge.tool. The list below shows the valid built-in values. Any other value\nis treated as a custom diff tool and requires that a corresponding difftool..cmd\nvariable is defined.\n\ndiff.guitool\nControls which diff tool is used by git-difftool(1) when the -g/--gui flag is specified.\nThis variable overrides the value configured in merge.guitool. The list below shows the\nvalid built-in values. Any other value is treated as a custom diff tool and requires that\na corresponding difftool..cmd variable is defined.\n\n• araxis\n\n• bc\n\n• bc3\n\n• bc4\n\n• codecompare\n\n• deltawalker\n\n• diffmerge\n\n• diffuse\n\n• ecmerge\n\n• emerge\n\n• examdiff\n\n• guiffy\n\n• gvimdiff\n\n• gvimdiff1\n\n• gvimdiff2\n\n• gvimdiff3\n\n• kdiff3\n\n• kompare\n\n• meld\n\n• nvimdiff\n\n• nvimdiff1\n\n• nvimdiff2\n\n• nvimdiff3\n\n• opendiff\n\n• p4merge\n\n• smerge\n\n• tkdiff\n\n• vimdiff\n\n• vimdiff1\n\n• vimdiff2\n\n• vimdiff3\n\n• winmerge\n\n• xxdiff\n\ndiff.indentHeuristic\nSet this option to false to disable the default heuristics that shift diff hunk\nboundaries to make patches easier to read.\n\ndiff.algorithm\nChoose a diff algorithm. The variants are as follows:\n\ndefault, myers\nThe basic greedy diff algorithm. Currently, this is the default.\n\nminimal\nSpend extra time to make sure the smallest possible diff is produced.\n\npatience\nUse \"patience diff\" algorithm when generating patches.\n\nhistogram\nThis algorithm extends the patience algorithm to \"support low-occurrence common\nelements\".\n\ndiff.wsErrorHighlight\nHighlight whitespace errors in the context, old or new lines of the diff. Multiple values\nare separated by comma, none resets previous values, default reset the list to new and\nall is a shorthand for old,new,context. The whitespace errors are colored with\ncolor.diff.whitespace. The command line option --ws-error-highlight= overrides this\nsetting.\n\ndiff.colorMoved\nIf set to either a valid or a true value, moved lines in a diff are colored\ndifferently, for details of valid modes see --color-moved in git-diff(1). If simply set\nto true the default color mode will be used. When set to false, moved lines are not\ncolored.\n\ndiff.colorMovedWS\nWhen moved lines are colored using e.g. the diff.colorMoved setting, this option controls\nthe how spaces are treated for details of valid modes see --color-moved-ws in git-\ndiff(1).\n\ndifftool..path\nOverride the path for the given tool. This is useful in case your tool is not in the\nPATH.\n\ndifftool..cmd\nSpecify the command to invoke the specified diff tool. The specified command is evaluated\nin shell with the following variables available: LOCAL is set to the name of the\ntemporary file containing the contents of the diff pre-image and REMOTE is set to the\nname of the temporary file containing the contents of the diff post-image.\n\ndifftool.prompt\nPrompt before each invocation of the diff tool.\n\nextensions.objectFormat\nSpecify the hash algorithm to use. The acceptable values are sha1 and sha256. If not\nspecified, sha1 is assumed. It is an error to specify this key unless\ncore.repositoryFormatVersion is 1.\n\nNote that this setting should only be set by git-init(1) or git-clone(1). Trying to\nchange it after initialization will not work and will produce hard-to-diagnose issues.\n\nfastimport.unpackLimit\nIf the number of objects imported by git-fast-import(1) is below this limit, then the\nobjects will be unpacked into loose object files. However if the number of imported\nobjects equals or exceeds this limit then the pack will be stored as a pack. Storing the\npack from a fast-import can make the import operation complete faster, especially on slow\nfilesystems. If not set, the value of transfer.unpackLimit is used instead.\n\nfeature.*\nThe config settings that start with feature. modify the defaults of a group of other\nconfig settings. These groups are created by the Git developer community as recommended\ndefaults and are subject to change. In particular, new config options may be added with\ndifferent defaults.\n\nfeature.experimental\nEnable config options that are new to Git, and are being considered for future defaults.\nConfig settings included here may be added or removed with each release, including minor\nversion updates. These settings may have unintended interactions since they are so new.\nPlease enable this setting if you are interested in providing feedback on experimental\nfeatures. The new default values are:\n\n• fetch.negotiationAlgorithm=skipping may improve fetch negotiation times by skipping\nmore commits at a time, reducing the number of round trips.\n\nfeature.manyFiles\nEnable config options that optimize for repos with many files in the working directory.\nWith many files, commands such as git status and git checkout may be slow and these new\ndefaults improve performance:\n\n• index.version=4 enables path-prefix compression in the index.\n\n• core.untrackedCache=true enables the untracked cache. This setting assumes that mtime\nis working on your machine.\n\nfetch.recurseSubmodules\nThis option controls whether git fetch (and the underlying fetch in git pull) will\nrecursively fetch into populated submodules. This option can be set either to a boolean\nvalue or to on-demand. Setting it to a boolean changes the behavior of fetch and pull to\nrecurse unconditionally into submodules when set to true or to not recurse at all when\nset to false. When set to on-demand, fetch and pull will only recurse into a populated\nsubmodule when its superproject retrieves a commit that updates the submodule’s\nreference. Defaults to on-demand, or to the value of submodule.recurse if set.\n\nfetch.fsckObjects\nIf it is set to true, git-fetch-pack will check all fetched objects. See\ntransfer.fsckObjects for what’s checked. Defaults to false. If not set, the value of\ntransfer.fsckObjects is used instead.\n\nfetch.fsck.\nActs like fsck., but is used by git-fetch-pack(1) instead of git-fsck(1). See the\nfsck. documentation for details.\n\nfetch.fsck.skipList\nActs like fsck.skipList, but is used by git-fetch-pack(1) instead of git-fsck(1). See the\nfsck.skipList documentation for details.\n\nfetch.unpackLimit\nIf the number of objects fetched over the Git native transfer is below this limit, then\nthe objects will be unpacked into loose object files. However if the number of received\nobjects equals or exceeds this limit then the received pack will be stored as a pack,\nafter adding any missing delta bases. Storing the pack from a push can make the push\noperation complete faster, especially on slow filesystems. If not set, the value of\ntransfer.unpackLimit is used instead.\n\nfetch.prune\nIf true, fetch will automatically behave as if the --prune option was given on the\ncommand line. See also remote..prune and the PRUNING section of git-fetch(1).\n\nfetch.pruneTags\nIf true, fetch will automatically behave as if the refs/tags/*:refs/tags/* refspec was\nprovided when pruning, if not set already. This allows for setting both this option and\nfetch.prune to maintain a 1=1 mapping to upstream refs. See also remote..pruneTags\nand the PRUNING section of git-fetch(1).\n\nfetch.output\nControl how ref update status is printed. Valid values are full and compact. Default\nvalue is full. See section OUTPUT in git-fetch(1) for detail.\n\nfetch.negotiationAlgorithm\nControl how information about the commits in the local repository is sent when\nnegotiating the contents of the packfile to be sent by the server. Set to \"skipping\" to\nuse an algorithm that skips commits in an effort to converge faster, but may result in a\nlarger-than-necessary packfile; or set to \"noop\" to not send any information at all,\nwhich will almost certainly result in a larger-than-necessary packfile, but will skip the\nnegotiation step. The default is \"default\" which instructs Git to use the default\nalgorithm that never skips commits (unless the server has acknowledged it or one of its\ndescendants). If feature.experimental is enabled, then this setting defaults to\n\"skipping\". Unknown values will cause git fetch to error out.\n\nSee also the --negotiate-only and --negotiation-tip options to git-fetch(1).\n\nfetch.showForcedUpdates\nSet to false to enable --no-show-forced-updates in git-fetch(1) and git-pull(1) commands.\nDefaults to true.\n\nfetch.parallel\nSpecifies the maximal number of fetch operations to be run in parallel at a time\n(submodules, or remotes when the --multiple option of git-fetch(1) is in effect).\n\nA value of 0 will give some reasonable default. If unset, it defaults to 1.\n\nFor submodules, this setting can be overridden using the submodule.fetchJobs config\nsetting.\n\nfetch.writeCommitGraph\nSet to true to write a commit-graph after every git fetch command that downloads a\npack-file from a remote. Using the --split option, most executions will create a very\nsmall commit-graph file on top of the existing commit-graph file(s). Occasionally, these\nfiles will merge and the write may take longer. Having an updated commit-graph file helps\nperformance of many Git commands, including git merge-base, git push -f, and git log\n--graph. Defaults to false.\n\nformat.attach\nEnable multipart/mixed attachments as the default for format-patch. The value can also be\na double quoted string which will enable attachments as the default and set the value as\nthe boundary. See the --attach option in git-format-patch(1).\n\nformat.from\nProvides the default value for the --from option to format-patch. Accepts a boolean\nvalue, or a name and email address. If false, format-patch defaults to --no-from, using\ncommit authors directly in the \"From:\" field of patch mails. If true, format-patch\ndefaults to --from, using your committer identity in the \"From:\" field of patch mails and\nincluding a \"From:\" field in the body of the patch mail if different. If set to a\nnon-boolean value, format-patch uses that value instead of your committer identity.\nDefaults to false.\n\nformat.numbered\nA boolean which can enable or disable sequence numbers in patch subjects. It defaults to\n\"auto\" which enables it only if there is more than one patch. It can be enabled or\ndisabled for all messages by setting it to \"true\" or \"false\". See --numbered option in\ngit-format-patch(1).\n\nformat.headers\nAdditional email headers to include in a patch to be submitted by mail. See git-format-\npatch(1).\n\nformat.to, format.cc\nAdditional recipients to include in a patch to be submitted by mail. See the --to and\n--cc options in git-format-patch(1).\n\nformat.subjectPrefix\nThe default for format-patch is to output files with the [PATCH] subject prefix. Use this\nvariable to change that prefix.\n\nformat.coverFromDescription\nThe default mode for format-patch to determine which parts of the cover letter will be\npopulated using the branch’s description. See the --cover-from-description option in git-\nformat-patch(1).\n\nformat.signature\nThe default for format-patch is to output a signature containing the Git version number.\nUse this variable to change that default. Set this variable to the empty string (\"\") to\nsuppress signature generation.\n\nformat.signatureFile\nWorks just like format.signature except the contents of the file specified by this\nvariable will be used as the signature.\n\nformat.suffix\nThe default for format-patch is to output files with the suffix .patch. Use this variable\nto change that suffix (make sure to include the dot if you want it).\n\nformat.encodeEmailHeaders\nEncode email headers that have non-ASCII characters with \"Q-encoding\" (described in RFC\n2047) for email transmission. Defaults to true.\n\nformat.pretty\nThe default pretty format for log/show/whatchanged command, See git-log(1), git-show(1),\ngit-whatchanged(1).\n\nformat.thread\nThe default threading style for git format-patch. Can be a boolean value, or shallow or\ndeep. shallow threading makes every mail a reply to the head of the series, where the\nhead is chosen from the cover letter, the --in-reply-to, and the first patch mail, in\nthis order. deep threading makes every mail a reply to the previous one. A true boolean\nvalue is the same as shallow, and a false value disables threading.\n\nformat.signOff\nA boolean value which lets you enable the -s/--signoff option of format-patch by default.\nNote: Adding the Signed-off-by trailer to a patch should be a conscious act and means\nthat you certify you have the rights to submit this work under the same open source\nlicense. Please see the SubmittingPatches document for further discussion.\n\nformat.coverLetter\nA boolean that controls whether to generate a cover-letter when format-patch is invoked,\nbut in addition can be set to \"auto\", to generate a cover-letter only when there’s more\nthan one patch. Default is false.\n\nformat.outputDirectory\nSet a custom directory to store the resulting files instead of the current working\ndirectory. All directory components will be created.\n\nformat.filenameMaxLength\nThe maximum length of the output filenames generated by the format-patch command;\ndefaults to 64. Can be overridden by the --filename-max-length= command line option.\n\nformat.useAutoBase\nA boolean value which lets you enable the --base=auto option of format-patch by default.\nCan also be set to \"whenAble\" to allow enabling --base=auto if a suitable base is\navailable, but to skip adding base info otherwise without the format dying.\n\nformat.notes\nProvides the default value for the --notes option to format-patch. Accepts a boolean\nvalue, or a ref which specifies where to get notes. If false, format-patch defaults to\n--no-notes. If true, format-patch defaults to --notes. If set to a non-boolean value,\nformat-patch defaults to --notes=, where ref is the non-boolean value. Defaults to\nfalse.\n\nIf one wishes to use the ref ref/notes/true, please use that literal instead.\n\nThis configuration can be specified multiple times in order to allow multiple notes refs\nto be included. In that case, it will behave similarly to multiple --[no-]notes[=]\noptions passed in. That is, a value of true will show the default notes, a value of \nwill also show notes from that notes ref and a value of false will negate previous\nconfigurations and not show notes.\n\nFor example,\n\n[format]\nnotes = true\nnotes = foo\nnotes = false\nnotes = bar\n\nwill only show notes from refs/notes/bar.\n\nfilter..clean\nThe command which is used to convert the content of a worktree file to a blob upon\ncheckin. See gitattributes(5) for details.\n\nfilter..smudge\nThe command which is used to convert the content of a blob object to a worktree file upon\ncheckout. See gitattributes(5) for details.\n\nfsck.\nDuring fsck git may find issues with legacy data which wouldn’t be generated by current\nversions of git, and which wouldn’t be sent over the wire if transfer.fsckObjects was\nset. This feature is intended to support working with legacy repositories containing such\ndata.\n\nSetting fsck. will be picked up by git-fsck(1), but to accept pushes of such data\nset receive.fsck. instead, or to clone or fetch it set fetch.fsck..\n\nThe rest of the documentation discusses fsck.* for brevity, but the same applies for the\ncorresponding receive.fsck.* and fetch..*. variables.\n\nUnlike variables like color.ui and core.editor the receive.fsck. and\nfetch.fsck. variables will not fall back on the fsck. configuration if\nthey aren’t set. To uniformly configure the same fsck settings in different circumstances\nall three of them they must all set to the same values.\n\nWhen fsck. is set, errors can be switched to warnings and vice versa by\nconfiguring the fsck. setting where the is the fsck message ID and the\nvalue is one of error, warn or ignore. For convenience, fsck prefixes the error/warning\nwith the message ID, e.g. \"missingEmail: invalid author/committer line - missing email\"\nmeans that setting fsck.missingEmail = ignore will hide that issue.\n\nIn general, it is better to enumerate existing objects with problems with fsck.skipList,\ninstead of listing the kind of breakages these problematic objects share to be ignored,\nas doing the latter will allow new instances of the same breakages go unnoticed.\n\nSetting an unknown fsck. value will cause fsck to die, but doing the same for\nreceive.fsck. and fetch.fsck. will only cause git to warn.\n\nfsck.skipList\nThe path to a list of object names (i.e. one unabbreviated SHA-1 per line) that are known\nto be broken in a non-fatal way and should be ignored. On versions of Git 2.20 and later\ncomments (#), empty lines, and any leading and trailing whitespace is ignored. Everything\nbut a SHA-1 per line will error out on older versions.\n\nThis feature is useful when an established project should be accepted despite early\ncommits containing errors that can be safely ignored such as invalid committer email\naddresses. Note: corrupt objects cannot be skipped with this setting.\n\nLike fsck. this variable has corresponding receive.fsck.skipList and\nfetch.fsck.skipList variants.\n\nUnlike variables like color.ui and core.editor the receive.fsck.skipList and\nfetch.fsck.skipList variables will not fall back on the fsck.skipList configuration if\nthey aren’t set. To uniformly configure the same fsck settings in different circumstances\nall three of them they must all set to the same values.\n\nOlder versions of Git (before 2.20) documented that the object names list should be\nsorted. This was never a requirement, the object names could appear in any order, but\nwhen reading the list we tracked whether the list was sorted for the purposes of an\ninternal binary search implementation, which could save itself some work with an already\nsorted list. Unless you had a humongous list there was no reason to go out of your way to\npre-sort the list. After Git version 2.20 a hash implementation is used instead, so\nthere’s now no reason to pre-sort the list.\n\ngc.aggressiveDepth\nThe depth parameter used in the delta compression algorithm used by git gc --aggressive.\nThis defaults to 50, which is the default for the --depth option when --aggressive isn’t\nin use.\n\nSee the documentation for the --depth option in git-repack(1) for more details.\n\ngc.aggressiveWindow\nThe window size parameter used in the delta compression algorithm used by git gc\n--aggressive. This defaults to 250, which is a much more aggressive window size than the\ndefault --window of 10.\n\nSee the documentation for the --window option in git-repack(1) for more details.\n\ngc.auto\nWhen there are approximately more than this many loose objects in the repository, git gc\n--auto will pack them. Some Porcelain commands use this command to perform a light-weight\ngarbage collection from time to time. The default value is 6700.\n\nSetting this to 0 disables not only automatic packing based on the number of loose\nobjects, but any other heuristic git gc --auto will otherwise use to determine if there’s\nwork to do, such as gc.autoPackLimit.\n\ngc.autoPackLimit\nWhen there are more than this many packs that are not marked with *.keep file in the\nrepository, git gc --auto consolidates them into one larger pack. The default value is\n50. Setting this to 0 disables it. Setting gc.auto to 0 will also disable this.\n\nSee the gc.bigPackThreshold configuration variable below. When in use, it’ll affect how\nthe auto pack limit works.\n\ngc.autoDetach\nMake git gc --auto return immediately and run in background if the system supports it.\nDefault is true.\n\ngc.bigPackThreshold\nIf non-zero, all packs larger than this limit are kept when git gc is run. This is very\nsimilar to --keep-largest-pack except that all packs that meet the threshold are kept,\nnot just the largest pack. Defaults to zero. Common unit suffixes of k, m, or g are\nsupported.\n\nNote that if the number of kept packs is more than gc.autoPackLimit, this configuration\nvariable is ignored, all packs except the base pack will be repacked. After this the\nnumber of packs should go below gc.autoPackLimit and gc.bigPackThreshold should be\nrespected again.\n\nIf the amount of memory estimated for git repack to run smoothly is not available and\ngc.bigPackThreshold is not set, the largest pack will also be excluded (this is the\nequivalent of running git gc with --keep-largest-pack).\n\ngc.writeCommitGraph\nIf true, then gc will rewrite the commit-graph file when git-gc(1) is run. When using git\ngc --auto the commit-graph will be updated if housekeeping is required. Default is true.\nSee git-commit-graph(1) for details.\n\ngc.logExpiry\nIf the file gc.log exists, then git gc --auto will print its content and exit with status\nzero instead of running unless that file is more than gc.logExpiry old. Default is\n\"1.day\". See gc.pruneExpire for more ways to specify its value.\n\ngc.packRefs\nRunning git pack-refs in a repository renders it unclonable by Git versions prior to\n1.5.1.2 over dumb transports such as HTTP. This variable determines whether git gc runs\ngit pack-refs. This can be set to notbare to enable it within all non-bare repos or it\ncan be set to a boolean value. The default is true.\n\ngc.pruneExpire\nWhen git gc is run, it will call prune --expire 2.weeks.ago. Override the grace period\nwith this config variable. The value \"now\" may be used to disable this grace period and\nalways prune unreachable objects immediately, or \"never\" may be used to suppress pruning.\nThis feature helps prevent corruption when git gc runs concurrently with another process\nwriting to the repository; see the \"NOTES\" section of git-gc(1).\n\ngc.worktreePruneExpire\nWhen git gc is run, it calls git worktree prune --expire 3.months.ago. This config\nvariable can be used to set a different grace period. The value \"now\" may be used to\ndisable the grace period and prune $GITDIR/worktrees immediately, or \"never\" may be used\nto suppress pruning.\n\ngc.reflogExpire, gc..reflogExpire\ngit reflog expire removes reflog entries older than this time; defaults to 90 days. The\nvalue \"now\" expires all entries immediately, and \"never\" suppresses expiration\naltogether. With \"\" (e.g. \"refs/stash\") in the middle the setting applies only\nto the refs that match the .\n\ngc.reflogExpireUnreachable, gc..reflogExpireUnreachable\ngit reflog expire removes reflog entries older than this time and are not reachable from\nthe current tip; defaults to 30 days. The value \"now\" expires all entries immediately,\nand \"never\" suppresses expiration altogether. With \"\" (e.g. \"refs/stash\") in the\nmiddle, the setting applies only to the refs that match the .\n\nThese types of entries are generally created as a result of using git commit --amend or\ngit rebase and are the commits prior to the amend or rebase occurring. Since these\nchanges are not part of the current project most users will want to expire them sooner,\nwhich is why the default is more aggressive than gc.reflogExpire.\n\ngc.rerereResolved\nRecords of conflicted merge you resolved earlier are kept for this many days when git\nrerere gc is run. You can also use more human-readable \"1.month.ago\", etc. The default is\n60 days. See git-rerere(1).\n\ngc.rerereUnresolved\nRecords of conflicted merge you have not resolved are kept for this many days when git\nrerere gc is run. You can also use more human-readable \"1.month.ago\", etc. The default is\n15 days. See git-rerere(1).\n\ngitcvs.commitMsgAnnotation\nAppend this string to each commit message. Set to empty string to disable this feature.\nDefaults to \"via git-CVS emulator\".\n\ngitcvs.enabled\nWhether the CVS server interface is enabled for this repository. See git-cvsserver(1).\n\ngitcvs.logFile\nPath to a log file where the CVS server interface well... logs various stuff. See git-\ncvsserver(1).\n\ngitcvs.usecrlfattr\nIf true, the server will look up the end-of-line conversion attributes for files to\ndetermine the -k modes to use. If the attributes force Git to treat a file as text, the\n-k mode will be left blank so CVS clients will treat it as text. If they suppress text\nconversion, the file will be set with -kb mode, which suppresses any newline munging the\nclient might otherwise do. If the attributes do not allow the file type to be determined,\nthen gitcvs.allBinary is used. See gitattributes(5).\n\ngitcvs.allBinary\nThis is used if gitcvs.usecrlfattr does not resolve the correct -kb mode to use. If true,\nall unresolved files are sent to the client in mode -kb. This causes the client to treat\nthem as binary files, which suppresses any newline munging it otherwise might do.\nAlternatively, if it is set to \"guess\", then the contents of the file are examined to\ndecide if it is binary, similar to core.autocrlf.\n\ngitcvs.dbName\nDatabase used by git-cvsserver to cache revision information derived from the Git\nrepository. The exact meaning depends on the used database driver, for SQLite (which is\nthe default driver) this is a filename. Supports variable substitution (see git-\ncvsserver(1) for details). May not contain semicolons (;). Default: %Ggitcvs.%m.sqlite\n\ngitcvs.dbDriver\nUsed Perl DBI driver. You can specify any available driver for this here, but it might\nnot work. git-cvsserver is tested with DBD::SQLite, reported to work with DBD::Pg, and\nreported not to work with DBD::mysql. Experimental feature. May not contain double colons\n(:). Default: SQLite. See git-cvsserver(1).\n\ngitcvs.dbUser, gitcvs.dbPass\nDatabase user and password. Only useful if setting gitcvs.dbDriver, since SQLite has no\nconcept of database users and/or passwords. gitcvs.dbUser supports variable substitution\n(see git-cvsserver(1) for details).\n\ngitcvs.dbTableNamePrefix\nDatabase table name prefix. Prepended to the names of any database tables used, allowing\na single database to be used for several repositories. Supports variable substitution\n(see git-cvsserver(1) for details). Any non-alphabetic characters will be replaced with\nunderscores.\n\nAll gitcvs variables except for gitcvs.usecrlfattr and gitcvs.allBinary can also be specified\nas gitcvs.. (where accessmethod is one of \"ext\" and \"pserver\") to\nmake them apply only for the given access method.\n\ngitweb.category, gitweb.description, gitweb.owner, gitweb.url\nSee gitweb(1) for description.\n\ngitweb.avatar, gitweb.blame, gitweb.grep, gitweb.highlight, gitweb.patches, gitweb.pickaxe,\ngitweb.remoteheads, gitweb.showSizes, gitweb.snapshot\nSee gitweb.conf(5) for description.\n\ngrep.lineNumber\nIf set to true, enable -n option by default.\n\ngrep.column\nIf set to true, enable the --column option by default.\n\ngrep.patternType\nSet the default matching behavior. Using a value of basic, extended, fixed, or perl will\nenable the --basic-regexp, --extended-regexp, --fixed-strings, or --perl-regexp option\naccordingly, while the value default will return to the default matching behavior.\n\ngrep.extendedRegexp\nIf set to true, enable --extended-regexp option by default. This option is ignored when\nthe grep.patternType option is set to a value other than default.\n\ngrep.threads\nNumber of grep worker threads to use. See grep.threads in git-grep(1) for more\ninformation.\n\ngrep.fallbackToNoIndex\nIf set to true, fall back to git grep --no-index if git grep is executed outside of a git\nrepository. Defaults to false.\n\ngpg.program\nUse this custom program instead of \"gpg\" found on $PATH when making or verifying a PGP\nsignature. The program must support the same command-line interface as GPG, namely, to\nverify a detached signature, \"gpg --verify $signature - <$file\" is run, and the program\nis expected to signal a good signature by exiting with code 0, and to generate an\nASCII-armored detached signature, the standard input of \"gpg -bsau $key\" is fed with the\ncontents to be signed, and the program is expected to send the result to its standard\noutput.\n\ngpg.format\nSpecifies which key format to use when signing with --gpg-sign. Default is \"openpgp\".\nOther possible values are \"x509\", \"ssh\".\n\ngpg..program\nUse this to customize the program used for the signing format you chose. (see gpg.program\nand gpg.format) gpg.program can still be used as a legacy synonym for\ngpg.openpgp.program. The default value for gpg.x509.program is \"gpgsm\" and\ngpg.ssh.program is \"ssh-keygen\".\n\ngpg.minTrustLevel\nSpecifies a minimum trust level for signature verification. If this option is unset, then\nsignature verification for merge operations require a key with at least marginal trust.\nOther operations that perform signature verification require a key with at least\nundefined trust. Setting this option overrides the required trust-level for all\noperations. Supported values, in increasing order of significance:\n\n• undefined\n\n• never\n\n• marginal\n\n• fully\n\n• ultimate\n\ngpg.ssh.defaultKeyCommand: This command that will be run when user.signingkey is not set and\na ssh signature is requested. On successful exit a valid ssh public key is expected in the\nfirst line of its output. To automatically use the first available key from your ssh-agent\nset this to \"ssh-add -L\".\n\ngpg.ssh.allowedSignersFile\nA file containing ssh public keys which you are willing to trust. The file consists of\none or more lines of principals followed by an ssh public key. e.g.:\nuser1@example.com[1],user2@example.com[2] ssh-rsa AAAAX1... See ssh-keygen(1) \"ALLOWED\nSIGNERS\" for details. The principal is only used to identify the key and is available\nwhen verifying a signature.\n\nSSH has no concept of trust levels like gpg does. To be able to differentiate between\nvalid signatures and trusted signatures the trust level of a signature verification is\nset to fully when the public key is present in the allowedSignersFile. Otherwise the\ntrust level is undefined and git verify-commit/tag will fail.\n\nThis file can be set to a location outside of the repository and every developer\nmaintains their own trust store. A central repository server could generate this file\nautomatically from ssh keys with push access to verify the code against. In a corporate\nsetting this file is probably generated at a global location from automation that already\nhandles developer ssh keys.\n\nA repository that only allows signed commits can store the file in the repository itself\nusing a path relative to the top-level of the working tree. This way only committers with\nan already valid key can add or change keys in the keyring.\n\nUsing a SSH CA key with the cert-authority option (see ssh-keygen(1) \"CERTIFICATES\") is\nalso valid.\n\ngpg.ssh.revocationFile\nEither a SSH KRL or a list of revoked public keys (without the principal prefix). See\nssh-keygen(1) for details. If a public key is found in this file then it will always be\ntreated as having trust level \"never\" and signatures will show as invalid.\n\ngui.commitMsgWidth\nDefines how wide the commit message window is in the git-gui(1). \"75\" is the default.\n\ngui.diffContext\nSpecifies how many context lines should be used in calls to diff made by the git-gui(1).\nThe default is \"5\".\n\ngui.displayUntracked\nDetermines if git-gui(1) shows untracked files in the file list. The default is \"true\".\n\ngui.encoding\nSpecifies the default character encoding to use for displaying of file contents in git-\ngui(1) and gitk(1). It can be overridden by setting the encoding attribute for relevant\nfiles (see gitattributes(5)). If this option is not set, the tools default to the locale\nencoding.\n\ngui.matchTrackingBranch\nDetermines if new branches created with git-gui(1) should default to tracking remote\nbranches with matching names or not. Default: \"false\".\n\ngui.newBranchTemplate\nIs used as suggested name when creating new branches using the git-gui(1).\n\ngui.pruneDuringFetch\n\"true\" if git-gui(1) should prune remote-tracking branches when performing a fetch. The\ndefault value is \"false\".\n\ngui.trustmtime\nDetermines if git-gui(1) should trust the file modification timestamp or not. By default\nthe timestamps are not trusted.\n\ngui.spellingDictionary\nSpecifies the dictionary used for spell checking commit messages in the git-gui(1). When\nset to \"none\" spell checking is turned off.\n\ngui.fastCopyBlame\nIf true, git gui blame uses -C instead of -C -C for original location detection. It makes\nblame significantly faster on huge repositories at the expense of less thorough copy\ndetection.\n\ngui.copyBlameThreshold\nSpecifies the threshold to use in git gui blame original location detection, measured in\nalphanumeric characters. See the git-blame(1) manual for more information on copy\ndetection.\n\ngui.blamehistoryctx\nSpecifies the radius of history context in days to show in gitk(1) for the selected\ncommit, when the Show History Context menu item is invoked from git gui blame. If this\nvariable is set to zero, the whole history is shown.\n\nguitool..cmd\nSpecifies the shell command line to execute when the corresponding item of the git-gui(1)\nTools menu is invoked. This option is mandatory for every tool. The command is executed\nfrom the root of the working directory, and in the environment it receives the name of\nthe tool as GITGUITOOL, the name of the currently selected file as FILENAME, and the\nname of the current branch as CURBRANCH (if the head is detached, CURBRANCH is empty).\n\nguitool..needsFile\nRun the tool only if a diff is selected in the GUI. It guarantees that FILENAME is not\nempty.\n\nguitool..noConsole\nRun the command silently, without creating a window to display its output.\n\nguitool..noRescan\nDon’t rescan the working directory for changes after the tool finishes execution.\n\nguitool..confirm\nShow a confirmation dialog before actually running the tool.\n\nguitool..argPrompt\nRequest a string argument from the user, and pass it to the tool through the ARGS\nenvironment variable. Since requesting an argument implies confirmation, the confirm\noption has no effect if this is enabled. If the option is set to true, yes, or 1, the\ndialog uses a built-in generic prompt; otherwise the exact value of the variable is used.\n\nguitool..revPrompt\nRequest a single valid revision from the user, and set the REVISION environment variable.\nIn other aspects this option is similar to argPrompt, and can be used together with it.\n\nguitool..revUnmerged\nShow only unmerged branches in the revPrompt subdialog. This is useful for tools similar\nto merge or rebase, but not for things like checkout or reset.\n\nguitool..title\nSpecifies the title to use for the prompt dialog. The default is the tool name.\n\nguitool..prompt\nSpecifies the general prompt string to display at the top of the dialog, before\nsubsections for argPrompt and revPrompt. The default value includes the actual command.\n\nhelp.browser\nSpecify the browser that will be used to display help in the web format. See git-help(1).\n\nhelp.format\nOverride the default help format used by git-help(1). Values man, info, web and html are\nsupported. man is the default. web and html are the same.\n\nhelp.autoCorrect\nIf git detects typos and can identify exactly one valid command similar to the error, git\nwill try to suggest the correct command or even run the suggestion automatically.\nPossible config values are:\n\n• 0 (default): show the suggested command.\n\n• positive number: run the suggested command after specified deciseconds (0.1 sec).\n\n• \"immediate\": run the suggested command immediately.\n\n• \"prompt\": show the suggestion and prompt for confirmation to run the command.\n\n• \"never\": don’t run or show any suggested command.\n\nhelp.htmlPath\nSpecify the path where the HTML documentation resides. File system paths and URLs are\nsupported. HTML pages will be prefixed with this path when help is displayed in the web\nformat. This defaults to the documentation path of your Git installation.\n\nhttp.proxy\nOverride the HTTP proxy, normally configured using the httpproxy, httpsproxy, and\nallproxy environment variables (see curl(1)). In addition to the syntax understood by\ncurl, it is possible to specify a proxy string with a user name but no password, in which\ncase git will attempt to acquire one in the same way it does for other credentials. See\ngitcredentials(7) for more information. The syntax thus is\n[protocol://][user[:password]@]proxyhost[:port]. This can be overridden on a per-remote\nbasis; see remote..proxy\n\nhttp.proxyAuthMethod\nSet the method with which to authenticate against the HTTP proxy. This only takes effect\nif the configured proxy string contains a user name part (i.e. is of the form user@host\nor user@host:port). This can be overridden on a per-remote basis; see\nremote..proxyAuthMethod. Both can be overridden by the GITHTTPPROXYAUTHMETHOD\nenvironment variable. Possible values are:\n\n• anyauth - Automatically pick a suitable authentication method. It is assumed that the\nproxy answers an unauthenticated request with a 407 status code and one or more\nProxy-authenticate headers with supported authentication methods. This is the\ndefault.\n\n• basic - HTTP Basic authentication\n\n• digest - HTTP Digest authentication; this prevents the password from being\ntransmitted to the proxy in clear text\n\n• negotiate - GSS-Negotiate authentication (compare the --negotiate option of curl(1))\n\n• ntlm - NTLM authentication (compare the --ntlm option of curl(1))\n\nhttp.proxySSLCert\nThe pathname of a file that stores a client certificate to use to authenticate with an\nHTTPS proxy. Can be overridden by the GITPROXYSSLCERT environment variable.\n\nhttp.proxySSLKey\nThe pathname of a file that stores a private key to use to authenticate with an HTTPS\nproxy. Can be overridden by the GITPROXYSSLKEY environment variable.\n\nhttp.proxySSLCertPasswordProtected\nEnable Git’s password prompt for the proxy SSL certificate. Otherwise OpenSSL will prompt\nthe user, possibly many times, if the certificate or private key is encrypted. Can be\noverridden by the GITPROXYSSLCERTPASSWORDPROTECTED environment variable.\n\nhttp.proxySSLCAInfo\nPathname to the file containing the certificate bundle that should be used to verify the\nproxy with when using an HTTPS proxy. Can be overridden by the GITPROXYSSLCAINFO\nenvironment variable.\n\nhttp.emptyAuth\nAttempt authentication without seeking a username or password. This can be used to\nattempt GSS-Negotiate authentication without specifying a username in the URL, as libcurl\nnormally requires a username for authentication.\n\nhttp.delegation\nControl GSSAPI credential delegation. The delegation is disabled by default in libcurl\nsince version 7.21.7. Set parameter to tell the server what it is allowed to delegate\nwhen it comes to user credentials. Used with GSS/kerberos. Possible values are:\n\n• none - Don’t allow any delegation.\n\n• policy - Delegates if and only if the OK-AS-DELEGATE flag is set in the Kerberos\nservice ticket, which is a matter of realm policy.\n\n• always - Unconditionally allow the server to delegate.\n\nhttp.extraHeader\nPass an additional HTTP header when communicating with a server. If more than one such\nentry exists, all of them are added as extra headers. To allow overriding the settings\ninherited from the system config, an empty value will reset the extra headers to the\nempty list.\n\nhttp.cookieFile\nThe pathname of a file containing previously stored cookie lines, which should be used in\nthe Git http session, if they match the server. The file format of the file to read\ncookies from should be plain HTTP headers or the Netscape/Mozilla cookie file format (see\ncurl(1)). NOTE that the file specified with http.cookieFile is used only as input unless\nhttp.saveCookies is set.\n\nhttp.saveCookies\nIf set, store cookies received during requests to the file specified by http.cookieFile.\nHas no effect if http.cookieFile is unset.\n\nhttp.version\nUse the specified HTTP protocol version when communicating with a server. If you want to\nforce the default. The available and default version depend on libcurl. Currently the\npossible values of this option are:\n\n• HTTP/2\n\n• HTTP/1.1\n\nhttp.sslVersion\nThe SSL version to use when negotiating an SSL connection, if you want to force the\ndefault. The available and default version depend on whether libcurl was built against\nNSS or OpenSSL and the particular configuration of the crypto library in use. Internally\nthis sets the CURLOPTSSLVERSION option; see the libcurl documentation for more details\non the format of this option and for the ssl version supported. Currently the possible\nvalues of this option are:\n\n• sslv2\n\n• sslv3\n\n• tlsv1\n\n• tlsv1.0\n\n• tlsv1.1\n\n• tlsv1.2\n\n• tlsv1.3\n\nCan be overridden by the GITSSLVERSION environment variable. To force git to use\nlibcurl’s default ssl version and ignore any explicit http.sslversion option, set\nGITSSLVERSION to the empty string.\n\nhttp.sslCipherList\nA list of SSL ciphers to use when negotiating an SSL connection. The available ciphers\ndepend on whether libcurl was built against NSS or OpenSSL and the particular\nconfiguration of the crypto library in use. Internally this sets the\nCURLOPTSSLCIPHERLIST option; see the libcurl documentation for more details on the\nformat of this list.\n\nCan be overridden by the GITSSLCIPHERLIST environment variable. To force git to use\nlibcurl’s default cipher list and ignore any explicit http.sslCipherList option, set\nGITSSLCIPHERLIST to the empty string.\n\nhttp.sslVerify\nWhether to verify the SSL certificate when fetching or pushing over HTTPS. Defaults to\ntrue. Can be overridden by the GITSSLNOVERIFY environment variable.\n\nhttp.sslCert\nFile containing the SSL certificate when fetching or pushing over HTTPS. Can be\noverridden by the GITSSLCERT environment variable.\n\nhttp.sslKey\nFile containing the SSL private key when fetching or pushing over HTTPS. Can be\noverridden by the GITSSLKEY environment variable.\n\nhttp.sslCertPasswordProtected\nEnable Git’s password prompt for the SSL certificate. Otherwise OpenSSL will prompt the\nuser, possibly many times, if the certificate or private key is encrypted. Can be\noverridden by the GITSSLCERTPASSWORDPROTECTED environment variable.\n\nhttp.sslCAInfo\nFile containing the certificates to verify the peer with when fetching or pushing over\nHTTPS. Can be overridden by the GITSSLCAINFO environment variable.\n\nhttp.sslCAPath\nPath containing files with the CA certificates to verify the peer with when fetching or\npushing over HTTPS. Can be overridden by the GITSSLCAPATH environment variable.\n\nhttp.sslBackend\nName of the SSL backend to use (e.g. \"openssl\" or \"schannel\"). This option is ignored if\ncURL lacks support for choosing the SSL backend at runtime.\n\nhttp.schannelCheckRevoke\nUsed to enforce or disable certificate revocation checks in cURL when http.sslBackend is\nset to \"schannel\". Defaults to true if unset. Only necessary to disable this if Git\nconsistently errors and the message is about checking the revocation status of a\ncertificate. This option is ignored if cURL lacks support for setting the relevant SSL\noption at runtime.\n\nhttp.schannelUseSSLCAInfo\nAs of cURL v7.60.0, the Secure Channel backend can use the certificate bundle provided\nvia http.sslCAInfo, but that would override the Windows Certificate Store. Since this is\nnot desirable by default, Git will tell cURL not to use that bundle by default when the\nschannel backend was configured via http.sslBackend, unless http.schannelUseSSLCAInfo\noverrides this behavior.\n\nhttp.pinnedpubkey\nPublic key of the https service. It may either be the filename of a PEM or DER encoded\npublic key file or a string starting with sha256// followed by the base64 encoded sha256\nhash of the public key. See also libcurl CURLOPTPINNEDPUBLICKEY. git will exit with an\nerror if this option is set but not supported by cURL.\n\nhttp.sslTry\nAttempt to use AUTH SSL/TLS and encrypted data transfers when connecting via regular FTP\nprotocol. This might be needed if the FTP server requires it for security reasons or you\nwish to connect securely whenever remote FTP server supports it. Default is false since\nit might trigger certificate verification errors on misconfigured servers.\n\nhttp.maxRequests\nHow many HTTP requests to launch in parallel. Can be overridden by the\nGITHTTPMAXREQUESTS environment variable. Default is 5.\n\nhttp.minSessions\nThe number of curl sessions (counted across slots) to be kept across requests. They will\nnot be ended with curleasycleanup() until httpcleanup() is invoked. If USECURLMULTI\nis not defined, this value will be capped at 1. Defaults to 1.\n\nhttp.postBuffer\nMaximum size in bytes of the buffer used by smart HTTP transports when POSTing data to\nthe remote system. For requests larger than this buffer size, HTTP/1.1 and\nTransfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default\nis 1 MiB, which is sufficient for most requests.\n\nNote that raising this limit is only effective for disabling chunked transfer encoding\nand therefore should be used only where the remote server or a proxy only supports\nHTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an\neffective solution for most push problems, but can increase memory consumption\nsignificantly since the entire buffer is allocated even for small pushes.\n\nhttp.lowSpeedLimit, http.lowSpeedTime\nIf the HTTP transfer speed is less than http.lowSpeedLimit for longer than\nhttp.lowSpeedTime seconds, the transfer is aborted. Can be overridden by the\nGITHTTPLOWSPEEDLIMIT and GITHTTPLOWSPEEDTIME environment variables.\n\nhttp.noEPSV\nA boolean which disables using of EPSV ftp command by curl. This can helpful with some\n\"poor\" ftp servers which don’t support EPSV mode. Can be overridden by the\nGITCURLFTPNOEPSV environment variable. Default is false (curl will use EPSV).\n\nhttp.userAgent\nThe HTTP USERAGENT string presented to an HTTP server. The default value represents the\nversion of the client Git such as git/1.7.1. This option allows you to override this\nvalue to a more common value such as Mozilla/4.0. This may be necessary, for instance, if\nconnecting through a firewall that restricts HTTP connections to a set of common\nUSERAGENT strings (but not including those like git/1.7.1). Can be overridden by the\nGITHTTPUSERAGENT environment variable.\n\nhttp.followRedirects\nWhether git should follow HTTP redirects. If set to true, git will transparently follow\nany redirect issued by a server it encounters. If set to false, git will treat all\nredirects as errors. If set to initial, git will follow redirects only for the initial\nrequest to a remote, but not for subsequent follow-up HTTP requests. Since git uses the\nredirected URL as the base for the follow-up requests, this is generally sufficient. The\ndefault is initial.\n\nhttp..*\nAny of the http.* options above can be applied selectively to some URLs. For a config key\nto match a URL, each element of the config key is compared to that of the URL, in the\nfollowing order:\n\n1. Scheme (e.g., https in https://example.com/). This field must match exactly between\nthe config key and the URL.\n\n2. Host/domain name (e.g., example.com in https://example.com/). This field must match\nbetween the config key and the URL. It is possible to specify a * as part of the host\nname to match all subdomains at this level. https://*.example.com/ for example would\nmatch https://foo.example.com/, but not https://foo.bar.example.com/.\n\n3. Port number (e.g., 8080 in http://example.com:8080/). This field must match exactly\nbetween the config key and the URL. Omitted port numbers are automatically converted\nto the correct default for the scheme before matching.\n\n4. Path (e.g., repo.git in https://example.com/repo.git). The path field of the config\nkey must match the path field of the URL either exactly or as a prefix of\nslash-delimited path elements. This means a config key with path foo/ matches URL\npath foo/bar. A prefix can only match on a slash (/) boundary. Longer matches take\nprecedence (so a config key with path foo/bar is a better match to URL path foo/bar\nthan a config key with just path foo/).\n\n5. User name (e.g., user in https://user@example.com/repo.git). If the config key has a\nuser name it must match the user name in the URL exactly. If the config key does not\nhave a user name, that config key will match a URL with any user name (including\nnone), but at a lower precedence than a config key with a user name.\n\nThe list above is ordered by decreasing precedence; a URL that matches a config key’s\npath is preferred to one that matches its user name. For example, if the URL is\nhttps://user@example.com/foo/bar a config key match of https://example.com/foo will be\npreferred over a config key match of https://user@example.com.\n\nAll URLs are normalized before attempting any matching (the password part, if embedded in\nthe URL, is always ignored for matching purposes) so that equivalent URLs that are simply\nspelled differently will match properly. Environment variable settings always override\nany matches. The URLs that are matched against are those given directly to Git commands.\nThis means any URLs visited as a result of a redirection do not participate in matching.\n\ni18n.commitEncoding\nCharacter encoding the commit messages are stored in; Git itself does not care per se,\nbut this information is necessary e.g. when importing commits from emails or in the gitk\ngraphical history browser (and possibly at other places in the future or in other\nporcelains). See e.g. git-mailinfo(1). Defaults to utf-8.\n\ni18n.logOutputEncoding\nCharacter encoding the commit messages are converted to when running git log and friends.\n\nimap.folder\nThe folder to drop the mails into, which is typically the Drafts folder. For example:\n\"INBOX.Drafts\", \"INBOX/Drafts\" or \"[Gmail]/Drafts\". Required.\n\nimap.tunnel\nCommand used to setup a tunnel to the IMAP server through which commands will be piped\ninstead of using a direct network connection to the server. Required when imap.host is\nnot set.\n\nimap.host\nA URL identifying the server. Use an imap:// prefix for non-secure connections and an\nimaps:// prefix for secure connections. Ignored when imap.tunnel is set, but required\notherwise.\n\nimap.user\nThe username to use when logging in to the server.\n\nimap.pass\nThe password to use when logging in to the server.\n\nimap.port\nAn integer port number to connect to on the server. Defaults to 143 for imap:// hosts and\n993 for imaps:// hosts. Ignored when imap.tunnel is set.\n\nimap.sslverify\nA boolean to enable/disable verification of the server certificate used by the SSL/TLS\nconnection. Default is true. Ignored when imap.tunnel is set.\n\nimap.preformattedHTML\nA boolean to enable/disable the use of html encoding when sending a patch. An html\nencoded patch will be bracketed with 
 and have a content type of text/html.\nIronically, enabling this option causes Thunderbird to send the patch as a plain/text,\nformat=fixed email. Default is false.\n\nimap.authMethod\nSpecify authenticate method for authentication with IMAP server. If Git was built with\nthe NOCURL option, or if your curl version is older than 7.34.0, or if you’re running\ngit-imap-send with the --no-curl option, the only supported method is CRAM-MD5. If this\nis not set then git imap-send uses the basic IMAP plaintext LOGIN command.\n\nindex.recordEndOfIndexEntries\nSpecifies whether the index file should include an \"End Of Index Entry\" section. This\nreduces index load time on multiprocessor machines but produces a message \"ignoring EOIE\nextension\" when reading the index using Git versions before 2.20. Defaults to true if\nindex.threads has been explicitly enabled, false otherwise.\n\nindex.recordOffsetTable\nSpecifies whether the index file should include an \"Index Entry Offset Table\" section.\nThis reduces index load time on multiprocessor machines but produces a message \"ignoring\nIEOT extension\" when reading the index using Git versions before 2.20. Defaults to true\nif index.threads has been explicitly enabled, false otherwise.\n\nindex.sparse\nWhen enabled, write the index using sparse-directory entries. This has no effect unless\ncore.sparseCheckout and core.sparseCheckoutCone are both enabled. Defaults to false.\n\nindex.threads\nSpecifies the number of threads to spawn when loading the index. This is meant to reduce\nindex load time on multiprocessor machines. Specifying 0 or true will cause Git to\nauto-detect the number of CPU’s and set the number of threads accordingly. Specifying 1\nor false will disable multithreading. Defaults to true.\n\nindex.version\nSpecify the version with which new index files should be initialized. This does not\naffect existing repositories. If feature.manyFiles is enabled, then the default is 4.\n\ninit.templateDir\nSpecify the directory from which templates will be copied. (See the \"TEMPLATE DIRECTORY\"\nsection of git-init(1).)\n\ninit.defaultBranch\nAllows overriding the default branch name e.g. when initializing a new repository.\n\ninstaweb.browser\nSpecify the program that will be used to browse your working repository in gitweb. See\ngit-instaweb(1).\n\ninstaweb.httpd\nThe HTTP daemon command-line to start gitweb on your working repository. See git-\ninstaweb(1).\n\ninstaweb.local\nIf true the web server started by git-instaweb(1) will be bound to the local IP\n(127.0.0.1).\n\ninstaweb.modulePath\nThe default module path for git-instaweb(1) to use instead of /usr/lib/apache2/modules.\nOnly used if httpd is Apache.\n\ninstaweb.port\nThe port number to bind the gitweb httpd to. See git-instaweb(1).\n\ninteractive.singleKey\nIn interactive commands, allow the user to provide one-letter input with a single key\n(i.e., without hitting enter). Currently this is used by the --patch mode of git-add(1),\ngit-checkout(1), git-restore(1), git-commit(1), git-reset(1), and git-stash(1). Note that\nthis setting is silently ignored if portable keystroke input is not available; requires\nthe Perl module Term::ReadKey.\n\ninteractive.diffFilter\nWhen an interactive command (such as git add --patch) shows a colorized diff, git will\npipe the diff through the shell command defined by this configuration variable. The\ncommand may mark up the diff further for human consumption, provided that it retains a\none-to-one correspondence with the lines in the original diff. Defaults to disabled (no\nfiltering).\n\nlog.abbrevCommit\nIf true, makes git-log(1), git-show(1), and git-whatchanged(1) assume --abbrev-commit.\nYou may override this option with --no-abbrev-commit.\n\nlog.date\nSet the default date-time mode for the log command. Setting a value for log.date is\nsimilar to using git log's --date option. See git-log(1) for details.\n\nlog.decorate\nPrint out the ref names of any commits that are shown by the log command. If short is\nspecified, the ref name prefixes refs/heads/, refs/tags/ and refs/remotes/ will not be\nprinted. If full is specified, the full ref name (including prefix) will be printed. If\nauto is specified, then if the output is going to a terminal, the ref names are shown as\nif short were given, otherwise no ref names are shown. This is the same as the --decorate\noption of the git log.\n\nlog.excludeDecoration\nExclude the specified patterns from the log decorations. This is similar to the\n--decorate-refs-exclude command-line option, but the config option can be overridden by\nthe --decorate-refs option.\n\nlog.diffMerges\nSet default diff format to be used for merge commits. See --diff-merges in git-log(1) for\ndetails. Defaults to separate.\n\nlog.follow\nIf true, git log will act as if the --follow option was used when a single  is\ngiven. This has the same limitations as --follow, i.e. it cannot be used to follow\nmultiple files and does not work well on non-linear history.\n\nlog.graphColors\nA list of colors, separated by commas, that can be used to draw history lines in git log\n--graph.\n\nlog.showRoot\nIf true, the initial commit will be shown as a big creation event. This is equivalent to\na diff against an empty tree. Tools like git-log(1) or git-whatchanged(1), which normally\nhide the root commit will now show it. True by default.\n\nlog.showSignature\nIf true, makes git-log(1), git-show(1), and git-whatchanged(1) assume --show-signature.\n\nlog.mailmap\nIf true, makes git-log(1), git-show(1), and git-whatchanged(1) assume --use-mailmap,\notherwise assume --no-use-mailmap. True by default.\n\nlsrefs.unborn\nMay be \"advertise\" (the default), \"allow\", or \"ignore\". If \"advertise\", the server will\nrespond to the client sending \"unborn\" (as described in protocol-v2.txt) and will\nadvertise support for this feature during the protocol v2 capability advertisement.\n\"allow\" is the same as \"advertise\" except that the server will not advertise support for\nthis feature; this is useful for load-balanced servers that cannot be updated atomically\n(for example), since the administrator could configure \"allow\", then after a delay,\nconfigure \"advertise\".\n\nmailinfo.scissors\nIf true, makes git-mailinfo(1) (and therefore git-am(1)) act by default as if the\n--scissors option was provided on the command-line. When active, this features removes\neverything from the message body before a scissors line (i.e. consisting mainly of \">8\",\n\"8<\" and \"-\").\n\nmailmap.file\nThe location of an augmenting mailmap file. The default mailmap, located in the root of\nthe repository, is loaded first, then the mailmap file pointed to by this variable. The\nlocation of the mailmap file may be in a repository subdirectory, or somewhere outside of\nthe repository itself. See git-shortlog(1) and git-blame(1).\n\nmailmap.blob\nLike mailmap.file, but consider the value as a reference to a blob in the repository. If\nboth mailmap.file and mailmap.blob are given, both are parsed, with entries from\nmailmap.file taking precedence. In a bare repository, this defaults to HEAD:.mailmap. In\na non-bare repository, it defaults to empty.\n\nmaintenance.auto\nThis boolean config option controls whether some commands run git maintenance run --auto\nafter doing their normal work. Defaults to true.\n\nmaintenance.strategy\nThis string config option provides a way to specify one of a few recommended schedules\nfor background maintenance. This only affects which tasks are run during git maintenance\nrun --schedule=X commands, provided no --task= arguments are provided. Further, if\na maintenance..schedule config value is set, then that value is used instead of the\none provided by maintenance.strategy. The possible strategy strings are:\n\n•   none: This default setting implies no task are run at any schedule.\n\n•   incremental: This setting optimizes for performing small maintenance activities that\ndo not delete any data. This does not schedule the gc task, but runs the prefetch and\ncommit-graph tasks hourly, the loose-objects and incremental-repack tasks daily, and\nthe pack-refs task weekly.\n\nmaintenance..enabled\nThis boolean config option controls whether the maintenance task with name  is run\nwhen no --task option is specified to git maintenance run. These config values are\nignored if a --task option exists. By default, only maintenance.gc.enabled is true.\n\nmaintenance..schedule\nThis config option controls whether or not the given  runs during a git maintenance\nrun --schedule= command. The value must be one of \"hourly\", \"daily\", or\n\"weekly\".\n\nmaintenance.commit-graph.auto\nThis integer config option controls how often the commit-graph task should be run as part\nof git maintenance run --auto. If zero, then the commit-graph task will not run with the\n--auto option. A negative value will force the task to run every time. Otherwise, a\npositive value implies the command should run when the number of reachable commits that\nare not in the commit-graph file is at least the value of maintenance.commit-graph.auto.\nThe default value is 100.\n\nmaintenance.loose-objects.auto\nThis integer config option controls how often the loose-objects task should be run as\npart of git maintenance run --auto. If zero, then the loose-objects task will not run\nwith the --auto option. A negative value will force the task to run every time.\nOtherwise, a positive value implies the command should run when the number of loose\nobjects is at least the value of maintenance.loose-objects.auto. The default value is\n100.\n\nmaintenance.incremental-repack.auto\nThis integer config option controls how often the incremental-repack task should be run\nas part of git maintenance run --auto. If zero, then the incremental-repack task will not\nrun with the --auto option. A negative value will force the task to run every time.\nOtherwise, a positive value implies the command should run when the number of pack-files\nnot in the multi-pack-index is at least the value of maintenance.incremental-repack.auto.\nThe default value is 10.\n\nman.viewer\nSpecify the programs that may be used to display help in the man format. See git-help(1).\n\nman..cmd\nSpecify the command to invoke the specified man viewer. The specified command is\nevaluated in shell with the man page passed as argument. (See git-help(1).)\n\nman..path\nOverride the path for the given tool that may be used to display help in the man format.\nSee git-help(1).\n\nmerge.conflictStyle\nSpecify the style in which conflicted hunks are written out to working tree files upon\nmerge. The default is \"merge\", which shows a <<<<<<< conflict marker, changes made by one\nside, a ======= marker, changes made by the other side, and then a >>>>>>> marker. An\nalternate style, \"diff3\", adds a ||||||| marker and the original text before the =======\nmarker.\n\nmerge.defaultToUpstream\nIf merge is called without any commit argument, merge the upstream branches configured\nfor the current branch by using their last observed values stored in their\nremote-tracking branches. The values of the branch..merge that name the\nbranches at the remote named by branch..remote are consulted, and then\nthey are mapped via remote..fetch to their corresponding remote-tracking\nbranches, and the tips of these tracking branches are merged. Defaults to true.\n\nmerge.ff\nBy default, Git does not create an extra merge commit when merging a commit that is a\ndescendant of the current commit. Instead, the tip of the current branch is\nfast-forwarded. When set to false, this variable tells Git to create an extra merge\ncommit in such a case (equivalent to giving the --no-ff option from the command line).\nWhen set to only, only such fast-forward merges are allowed (equivalent to giving the\n--ff-only option from the command line).\n\nmerge.verifySignatures\nIf true, this is equivalent to the --verify-signatures command line option. See git-\nmerge(1) for details.\n\nmerge.branchdesc\nIn addition to branch names, populate the log message with the branch description text\nassociated with them. Defaults to false.\n\nmerge.log\nIn addition to branch names, populate the log message with at most the specified number\nof one-line descriptions from the actual commits that are being merged. Defaults to\nfalse, and true is a synonym for 20.\n\nmerge.suppressDest\nBy adding a glob that matches the names of integration branches to this multi-valued\nconfiguration variable, the default merge message computed for merges into these\nintegration branches will omit \"into \" from its title.\n\nAn element with an empty value can be used to clear the list of globs accumulated from\nprevious configuration entries. When there is no merge.suppressDest variable defined, the\ndefault value of master is used for backward compatibility.\n\nmerge.renameLimit\nThe number of files to consider in the exhaustive portion of rename detection during a\nmerge. If not specified, defaults to the value of diff.renameLimit. If neither\nmerge.renameLimit nor diff.renameLimit are specified, currently defaults to 7000. This\nsetting has no effect if rename detection is turned off.\n\nmerge.renames\nWhether Git detects renames. If set to \"false\", rename detection is disabled. If set to\n\"true\", basic rename detection is enabled. Defaults to the value of diff.renames.\n\nmerge.directoryRenames\nWhether Git detects directory renames, affecting what happens at merge time to new files\nadded to a directory on one side of history when that directory was renamed on the other\nside of history. If merge.directoryRenames is set to \"false\", directory rename detection\nis disabled, meaning that such new files will be left behind in the old directory. If set\nto \"true\", directory rename detection is enabled, meaning that such new files will be\nmoved into the new directory. If set to \"conflict\", a conflict will be reported for such\npaths. If merge.renames is false, merge.directoryRenames is ignored and treated as false.\nDefaults to \"conflict\".\n\nmerge.renormalize\nTell Git that canonical representation of files in the repository has changed over time\n(e.g. earlier commits record text files with CRLF line endings, but recent ones use LF\nline endings). In such a repository, Git can convert the data recorded in commits to a\ncanonical form before performing a merge to reduce unnecessary conflicts. For more\ninformation, see section \"Merging branches with differing checkin/checkout attributes\" in\ngitattributes(5).\n\nmerge.stat\nWhether to print the diffstat between ORIGHEAD and the merge result at the end of the\nmerge. True by default.\n\nmerge.autoStash\nWhen set to true, automatically create a temporary stash entry before the operation\nbegins, and apply it after the operation ends. This means that you can run merge on a\ndirty worktree. However, use with care: the final stash application after a successful\nmerge might result in non-trivial conflicts. This option can be overridden by the\n--no-autostash and --autostash options of git-merge(1). Defaults to false.\n\nmerge.tool\nControls which merge tool is used by git-mergetool(1). The list below shows the valid\nbuilt-in values. Any other value is treated as a custom merge tool and requires that a\ncorresponding mergetool..cmd variable is defined.\n\nmerge.guitool\nControls which merge tool is used by git-mergetool(1) when the -g/--gui flag is\nspecified. The list below shows the valid built-in values. Any other value is treated as\na custom merge tool and requires that a corresponding mergetool..cmd variable is\ndefined.\n\n•   araxis\n\n•   bc\n\n•   bc3\n\n•   bc4\n\n•   codecompare\n\n•   deltawalker\n\n•   diffmerge\n\n•   diffuse\n\n•   ecmerge\n\n•   emerge\n\n•   examdiff\n\n•   guiffy\n\n•   gvimdiff\n\n•   gvimdiff1\n\n•   gvimdiff2\n\n•   gvimdiff3\n\n•   kdiff3\n\n•   meld\n\n•   nvimdiff\n\n•   nvimdiff1\n\n•   nvimdiff2\n\n•   nvimdiff3\n\n•   opendiff\n\n•   p4merge\n\n•   smerge\n\n•   tkdiff\n\n•   tortoisemerge\n\n•   vimdiff\n\n•   vimdiff1\n\n•   vimdiff2\n\n•   vimdiff3\n\n•   winmerge\n\n•   xxdiff\n\nmerge.verbosity\nControls the amount of output shown by the recursive merge strategy. Level 0 outputs\nnothing except a final error message if conflicts were detected. Level 1 outputs only\nconflicts, 2 outputs conflicts and file changes. Level 5 and above outputs debugging\ninformation. The default is level 2. Can be overridden by the GITMERGEVERBOSITY\nenvironment variable.\n\nmerge..name\nDefines a human-readable name for a custom low-level merge driver. See gitattributes(5)\nfor details.\n\nmerge..driver\nDefines the command that implements a custom low-level merge driver. See gitattributes(5)\nfor details.\n\nmerge..recursive\nNames a low-level merge driver to be used when performing an internal merge between\ncommon ancestors. See gitattributes(5) for details.\n\nmergetool..path\nOverride the path for the given tool. This is useful in case your tool is not in the\nPATH.\n\nmergetool..cmd\nSpecify the command to invoke the specified merge tool. The specified command is\nevaluated in shell with the following variables available: BASE is the name of a\ntemporary file containing the common base of the files to be merged, if available; LOCAL\nis the name of a temporary file containing the contents of the file on the current\nbranch; REMOTE is the name of a temporary file containing the contents of the file from\nthe branch being merged; MERGED contains the name of the file to which the merge tool\nshould write the results of a successful merge.\n\nmergetool..hideResolved\nAllows the user to override the global mergetool.hideResolved value for a specific tool.\nSee mergetool.hideResolved for the full description.\n\nmergetool..trustExitCode\nFor a custom merge command, specify whether the exit code of the merge command can be\nused to determine whether the merge was successful. If this is not set to true then the\nmerge target file timestamp is checked and the merge assumed to have been successful if\nthe file has been updated, otherwise the user is prompted to indicate the success of the\nmerge.\n\nmergetool.meld.hasOutput\nOlder versions of meld do not support the --output option. Git will attempt to detect\nwhether meld supports --output by inspecting the output of meld --help. Configuring\nmergetool.meld.hasOutput will make Git skip these checks and use the configured value\ninstead. Setting mergetool.meld.hasOutput to true tells Git to unconditionally use the\n--output option, and false avoids using --output.\n\nmergetool.meld.useAutoMerge\nWhen the --auto-merge is given, meld will merge all non-conflicting parts automatically,\nhighlight the conflicting parts and wait for user decision. Setting\nmergetool.meld.useAutoMerge to true tells Git to unconditionally use the --auto-merge\noption with meld. Setting this value to auto makes git detect whether --auto-merge is\nsupported and will only use --auto-merge when available. A value of false avoids using\n--auto-merge altogether, and is the default value.\n\nmergetool.hideResolved\nDuring a merge Git will automatically resolve as many conflicts as possible and write the\nMERGED file containing conflict markers around any conflicts that it cannot resolve;\nLOCAL and REMOTE normally represent the versions of the file from before Git’s conflict\nresolution. This flag causes LOCAL and REMOTE to be overwriten so that only the\nunresolved conflicts are presented to the merge tool. Can be configured per-tool via the\nmergetool..hideResolved configuration variable. Defaults to false.\n\nmergetool.keepBackup\nAfter performing a merge, the original file with conflict markers can be saved as a file\nwith a .orig extension. If this variable is set to false then this file is not preserved.\nDefaults to true (i.e. keep the backup files).\n\nmergetool.keepTemporaries\nWhen invoking a custom merge tool, Git uses a set of temporary files to pass to the tool.\nIf the tool returns an error and this variable is set to true, then these temporary files\nwill be preserved, otherwise they will be removed after the tool has exited. Defaults to\nfalse.\n\nmergetool.writeToTemp\nGit writes temporary BASE, LOCAL, and REMOTE versions of conflicting files in the\nworktree by default. Git will attempt to use a temporary directory for these files when\nset true. Defaults to false.\n\nmergetool.prompt\nPrompt before each invocation of the merge resolution program.\n\nnotes.mergeStrategy\nWhich merge strategy to choose by default when resolving notes conflicts. Must be one of\nmanual, ours, theirs, union, or catsortuniq. Defaults to manual. See \"NOTES MERGE\nSTRATEGIES\" section of git-notes(1) for more information on each strategy.\n\nnotes..mergeStrategy\nWhich merge strategy to choose when doing a notes merge into refs/notes/. This\noverrides the more general \"notes.mergeStrategy\". See the \"NOTES MERGE STRATEGIES\"\nsection in git-notes(1) for more information on the available strategies.\n\nnotes.displayRef\nThe (fully qualified) refname from which to show notes when showing commit messages. The\nvalue of this variable can be set to a glob, in which case notes from all matching refs\nwill be shown. You may also specify this configuration variable several times. A warning\nwill be issued for refs that do not exist, but a glob that does not match any refs is\nsilently ignored.\n\nThis setting can be overridden with the GITNOTESDISPLAYREF environment variable, which\nmust be a colon separated list of refs or globs.\n\nThe effective value of \"core.notesRef\" (possibly overridden by GITNOTESREF) is also\nimplicitly added to the list of refs to be displayed.\n\nnotes.rewrite.\nWhen rewriting commits with  (currently amend or rebase) and this variable is\nset to true, Git automatically copies your notes from the original to the rewritten\ncommit. Defaults to true, but see \"notes.rewriteRef\" below.\n\nnotes.rewriteMode\nWhen copying notes during a rewrite (see the \"notes.rewrite.\" option),\ndetermines what to do if the target commit already has a note. Must be one of overwrite,\nconcatenate, catsortuniq, or ignore. Defaults to concatenate.\n\nThis setting can be overridden with the GITNOTESREWRITEMODE environment variable.\n\nnotes.rewriteRef\nWhen copying notes during a rewrite, specifies the (fully qualified) ref whose notes\nshould be copied. The ref may be a glob, in which case notes in all matching refs will be\ncopied. You may also specify this configuration several times.\n\nDoes not have a default value; you must configure this variable to enable note rewriting.\nSet it to refs/notes/commits to enable rewriting for the default commit notes.\n\nThis setting can be overridden with the GITNOTESREWRITEREF environment variable, which\nmust be a colon separated list of refs or globs.\n\npack.window\nThe size of the window used by git-pack-objects(1) when no window size is given on the\ncommand line. Defaults to 10.\n\npack.depth\nThe maximum delta depth used by git-pack-objects(1) when no maximum depth is given on the\ncommand line. Defaults to 50. Maximum value is 4095.\n\npack.windowMemory\nThe maximum size of memory that is consumed by each thread in git-pack-objects(1) for\npack window memory when no limit is given on the command line. The value can be suffixed\nwith \"k\", \"m\", or \"g\". When left unconfigured (or set explicitly to 0), there will be no\nlimit.\n\npack.compression\nAn integer -1..9, indicating the compression level for objects in a pack file. -1 is the\nzlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being\nslowest. If not set, defaults to core.compression. If that is not set, defaults to -1,\nthe zlib default, which is \"a default compromise between speed and compression (currently\nequivalent to level 6).\"\n\nNote that changing the compression level will not automatically recompress all existing\nobjects. You can force recompression by passing the -F option to git-repack(1).\n\npack.allowPackReuse\nWhen true, and when reachability bitmaps are enabled, pack-objects will try to send parts\nof the bitmapped packfile verbatim. This can reduce memory and CPU usage to serve\nfetches, but might result in sending a slightly larger pack. Defaults to true.\n\npack.island\nAn extended regular expression configuring a set of delta islands. See \"DELTA ISLANDS\" in\ngit-pack-objects(1) for details.\n\npack.islandCore\nSpecify an island name which gets to have its objects be packed first. This creates a\nkind of pseudo-pack at the front of one pack, so that the objects from the specified\nisland are hopefully faster to copy into any pack that should be served to a user\nrequesting these objects. In practice this means that the island specified should likely\ncorrespond to what is the most commonly cloned in the repo. See also \"DELTA ISLANDS\" in\ngit-pack-objects(1).\n\npack.deltaCacheSize\nThe maximum memory in bytes used for caching deltas in git-pack-objects(1) before writing\nthem out to a pack. This cache is used to speed up the writing object phase by not having\nto recompute the final delta result once the best match for all objects is found.\nRepacking large repositories on machines which are tight with memory might be badly\nimpacted by this though, especially if this cache pushes the system into swapping. A\nvalue of 0 means no limit. The smallest size of 1 byte may be used to virtually disable\nthis cache. Defaults to 256 MiB.\n\npack.deltaCacheLimit\nThe maximum size of a delta, that is cached in git-pack-objects(1). This cache is used to\nspeed up the writing object phase by not having to recompute the final delta result once\nthe best match for all objects is found. Defaults to 1000. Maximum value is 65535.\n\npack.threads\nSpecifies the number of threads to spawn when searching for best delta matches. This\nrequires that git-pack-objects(1) be compiled with pthreads otherwise this option is\nignored with a warning. This is meant to reduce packing time on multiprocessor machines.\nThe required amount of memory for the delta search window is however multiplied by the\nnumber of threads. Specifying 0 will cause Git to auto-detect the number of CPU’s and set\nthe number of threads accordingly.\n\npack.indexVersion\nSpecify the default pack index version. Valid values are 1 for legacy pack index used by\nGit versions prior to 1.5.2, and 2 for the new pack index with capabilities for packs\nlarger than 4 GB as well as proper protection against the repacking of corrupted packs.\nVersion 2 is the default. Note that version 2 is enforced and this config option ignored\nwhenever the corresponding pack is larger than 2 GB.\n\nIf you have an old Git that does not understand the version 2 *.idx file, cloning or\nfetching over a non native protocol (e.g. \"http\") that will copy both *.pack file and\ncorresponding *.idx file from the other side may give you a repository that cannot be\naccessed with your older version of Git. If the *.pack file is smaller than 2 GB,\nhowever, you can use git-index-pack(1) on the *.pack file to regenerate the *.idx file.\n\npack.packSizeLimit\nThe maximum size of a pack. This setting only affects packing to a file when repacking,\ni.e. the git:// protocol is unaffected. It can be overridden by the --max-pack-size\noption of git-repack(1). Reaching this limit results in the creation of multiple\npackfiles.\n\nNote that this option is rarely useful, and may result in a larger total on-disk size\n(because Git will not store deltas between packs), as well as worse runtime performance\n(object lookup within multiple packs is slower than a single pack, and optimizations like\nreachability bitmaps cannot cope with multiple packs).\n\nIf you need to actively run Git using smaller packfiles (e.g., because your filesystem\ndoes not support large files), this option may help. But if your goal is to transmit a\npackfile over a medium that supports limited sizes (e.g., removable media that cannot\nstore the whole repository), you are likely better off creating a single large packfile\nand splitting it using a generic multi-volume archive tool (e.g., Unix split).\n\nThe minimum size allowed is limited to 1 MiB. The default is unlimited. Common unit\nsuffixes of k, m, or g are supported.\n\npack.useBitmaps\nWhen true, git will use pack bitmaps (if available) when packing to stdout (e.g., during\nthe server side of a fetch). Defaults to true. You should not generally need to turn this\noff unless you are debugging pack bitmaps.\n\npack.useSparse\nWhen true, git will default to using the --sparse option in git pack-objects when the\n--revs option is present. This algorithm only walks trees that appear in paths that\nintroduce new objects. This can have significant performance benefits when computing a\npack to send a small change. However, it is possible that extra objects are added to the\npack-file if the included commits contain certain types of direct renames. Default is\ntrue.\n\npack.preferBitmapTips\nWhen selecting which commits will receive bitmaps, prefer a commit at the tip of any\nreference that is a suffix of any value of this configuration over any other commits in\nthe \"selection window\".\n\nNote that setting this configuration to refs/foo does not mean that the commits at the\ntips of refs/foo/bar and refs/foo/baz will necessarily be selected. This is because\ncommits are selected for bitmaps from within a series of windows of variable length.\n\nIf a commit at the tip of any reference which is a suffix of any value of this\nconfiguration is seen in a window, it is immediately given preference over any other\ncommit in that window.\n\npack.writeBitmaps (deprecated)\nThis is a deprecated synonym for repack.writeBitmaps.\n\npack.writeBitmapHashCache\nWhen true, git will include a \"hash cache\" section in the bitmap index (if one is\nwritten). This cache can be used to feed git’s delta heuristics, potentially leading to\nbetter deltas between bitmapped and non-bitmapped objects (e.g., when serving a fetch\nbetween an older, bitmapped pack and objects that have been pushed since the last gc).\nThe downside is that it consumes 4 bytes per object of disk space. Defaults to true.\n\nWhen writing a multi-pack reachability bitmap, no new namehashes are computed; instead,\nany namehashes stored in an existing bitmap are permuted into their appropriate location\nwhen writing a new bitmap.\n\npack.writeReverseIndex\nWhen true, git will write a corresponding .rev file (see:\nDocumentation/technical/pack-format.txt[3]) for each new packfile that it writes in all\nplaces except for git-fast-import(1) and in the bulk checkin mechanism. Defaults to\nfalse.\n\npager.\nIf the value is boolean, turns on or off pagination of the output of a particular Git\nsubcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using\nthe pager specified by the value of pager.. If --paginate or --no-pager is specified\non the command line, it takes precedence over this option. To disable pagination for all\ncommands, set core.pager or GITPAGER to cat.\n\npretty.\nAlias for a --pretty= format string, as specified in git-log(1). Any aliases defined here\ncan be used just as the built-in pretty formats could. For example, running git config\npretty.changelog \"format:* %H %s\" would cause the invocation git log --pretty=changelog\nto be equivalent to running git log \"--pretty=format:* %H %s\". Note that an alias with\nthe same name as a built-in format will be silently ignored.\n\nprotocol.allow\nIf set, provide a user defined default policy for all protocols which don’t explicitly\nhave a policy (protocol..allow). By default, if unset, known-safe protocols (http,\nhttps, git, ssh) have a default policy of always, known-dangerous protocols (ext) have a\ndefault policy of never, and all other protocols (including file) have a default policy\nof user. Supported policies:\n\n•   always - protocol is always able to be used.\n\n•   never - protocol is never able to be used.\n\n•   user - protocol is only able to be used when GITPROTOCOLFROMUSER is either unset\nor has a value of 1. This policy should be used when you want a protocol to be\ndirectly usable by the user but don’t want it used by commands which execute\nclone/fetch/push commands without user input, e.g. recursive submodule\ninitialization.\n\nprotocol..allow\nSet a policy to be used by protocol  with clone/fetch/push commands. See\nprotocol.allow above for the available policies.\n\nThe protocol names currently used by git are:\n\n•   file: any local file-based path (including file:// URLs, or local paths)\n\n•   git: the anonymous git protocol over a direct TCP connection (or proxy, if\nconfigured)\n\n•   ssh: git over ssh (including host:path syntax, ssh://, etc).\n\n•   http: git over http, both \"smart http\" and \"dumb http\". Note that this does not\ninclude https; if you want to configure both, you must do so individually.\n\n•   any external helpers are named by their protocol (e.g., use hg to allow the\ngit-remote-hg helper)\n\nprotocol.version\nIf set, clients will attempt to communicate with a server using the specified protocol\nversion. If the server does not support it, communication falls back to version 0. If\nunset, the default is 2. Supported versions:\n\n•   0 - the original wire protocol.\n\n•   1 - the original wire protocol with the addition of a version string in the initial\nresponse from the server.\n\n•   2 - wire protocol version 2[4].\n\npull.ff\nBy default, Git does not create an extra merge commit when merging a commit that is a\ndescendant of the current commit. Instead, the tip of the current branch is\nfast-forwarded. When set to false, this variable tells Git to create an extra merge\ncommit in such a case (equivalent to giving the --no-ff option from the command line).\nWhen set to only, only such fast-forward merges are allowed (equivalent to giving the\n--ff-only option from the command line). This setting overrides merge.ff when pulling.\n\npull.rebase\nWhen true, rebase branches on top of the fetched branch, instead of merging the default\nbranch from the default remote when \"git pull\" is run. See \"branch..rebase\" for\nsetting this on a per-branch basis.\n\nWhen merges (or just m), pass the --rebase-merges option to git rebase so that the local\nmerge commits are included in the rebase (see git-rebase(1) for details).\n\nWhen the value is interactive (or just i), the rebase is run in interactive mode.\n\nNOTE: this is a possibly dangerous operation; do not use it unless you understand the\nimplications (see git-rebase(1) for details).\n\npull.octopus\nThe default merge strategy to use when pulling multiple branches at once.\n\npull.twohead\nThe default merge strategy to use when pulling a single branch.\n\npush.default\nDefines the action git push should take if no refspec is given (whether from the\ncommand-line, config, or elsewhere). Different values are well-suited for specific\nworkflows; for instance, in a purely central workflow (i.e. the fetch source is equal to\nthe push destination), upstream is probably what you want. Possible values are:\n\n•   nothing - do not push anything (error out) unless a refspec is given. This is\nprimarily meant for people who want to avoid mistakes by always being explicit.\n\n•   current - push the current branch to update a branch with the same name on the\nreceiving end. Works in both central and non-central workflows.\n\n•   upstream - push the current branch back to the branch whose changes are usually\nintegrated into the current branch (which is called @{upstream}). This mode only\nmakes sense if you are pushing to the same repository you would normally pull from\n(i.e. central workflow).\n\n•   tracking - This is a deprecated synonym for upstream.\n\n•   simple - pushes the current branch with the same name on the remote.\n\nIf you are working on a centralized workflow (pushing to the same repository you pull\nfrom, which is typically origin), then you need to configure an upstream branch with\nthe same name.\n\nThis mode is the default since Git 2.0, and is the safest option suited for\nbeginners.\n\n•   matching - push all branches having the same name on both ends. This makes the\nrepository you are pushing to remember the set of branches that will be pushed out\n(e.g. if you always push maint and master there and no other branches, the repository\nyou push to will have these two branches, and your local maint and master will be\npushed there).\n\nTo use this mode effectively, you have to make sure all the branches you would push\nout are ready to be pushed out before running git push, as the whole point of this\nmode is to allow you to push all of the branches in one go. If you usually finish\nwork on only one branch and push out the result, while other branches are unfinished,\nthis mode is not for you. Also this mode is not suitable for pushing into a shared\ncentral repository, as other people may add new branches there, or update the tip of\nexisting branches outside your control.\n\nThis used to be the default, but not since Git 2.0 (simple is the new default).\n\npush.followTags\nIf set to true enable --follow-tags option by default. You may override this\nconfiguration at time of push by specifying --no-follow-tags.\n\npush.gpgSign\nMay be set to a boolean value, or the string if-asked. A true value causes all pushes to\nbe GPG signed, as if --signed is passed to git-push(1). The string if-asked causes pushes\nto be signed if the server supports it, as if --signed=if-asked is passed to git push. A\nfalse value may override a value from a lower-priority config file. An explicit\ncommand-line flag always overrides this config option.\n\npush.pushOption\nWhen no --push-option=