4 The Git configuration file contains a number of variables that affect
5 the Git commands' behavior. The files `.git/config` and optionally
6 `config.worktree` (see the "CONFIGURATION FILE" section of
7 linkgit:git-worktree[1]) in each repository are used to store the
8 configuration for that repository, and `$HOME/.gitconfig` is used to
9 store a per-user configuration as fallback values for the `.git/config`
10 file. The file `/etc/gitconfig` can be used to store a system-wide
11 default configuration.
13 The configuration variables are used by both the Git plumbing
14 and the porcelains. The variables are divided into sections, wherein
15 the fully qualified variable name of the variable itself is the last
16 dot-separated segment and the section name is everything before the last
17 dot. The variable names are case-insensitive, allow only alphanumeric
18 characters and `-`, and must start with an alphabetic character. Some
19 variables may appear multiple times; we say then that the variable is
25 The syntax is fairly flexible and permissive; whitespaces are mostly
26 ignored. The '#' and ';' characters begin comments to the end of line,
27 blank lines are ignored.
29 The file consists of sections and variables. A section begins with
30 the name of the section in square brackets and continues until the next
31 section begins. Section names are case-insensitive. Only alphanumeric
32 characters, `-` and `.` are allowed in section names. Each variable
33 must belong to some section, which means that there must be a section
34 header before the first setting of a variable.
36 Sections can be further divided into subsections. To begin a subsection
37 put its name in double quotes, separated by space from the section name,
38 in the section header, like in the example below:
41 [section "subsection"]
45 Subsection names are case sensitive and can contain any characters except
46 newline and the null byte. Doublequote `"` and backslash can be included
47 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
48 other characters are dropped when reading; for example, `\t` is read as
49 `t` and `\0` is read as `0`. Section headers cannot span multiple lines.
50 Variables may belong directly to a section or to a given subsection. You
51 can have `[section]` if you have `[section "subsection"]`, but you don't
54 There is also a deprecated `[section.subsection]` syntax. With this
55 syntax, the subsection name is converted to lower-case and is also
56 compared case sensitively. These subsection names follow the same
57 restrictions as section names.
59 All the other lines (and the remainder of the line after the section
60 header) are recognized as setting variables, in the form
61 'name = value' (or just 'name', which is a short-hand to say that
62 the variable is the boolean "true").
63 The variable names are case-insensitive, allow only alphanumeric characters
64 and `-`, and must start with an alphabetic character.
66 A line that defines a value can be continued to the next line by
67 ending it with a `\`; the backslash and the end-of-line are
68 stripped. Leading whitespaces after 'name =', the remainder of the
69 line after the first comment character '#' or ';', and trailing
70 whitespaces of the line are discarded unless they are enclosed in
71 double quotes. Internal whitespaces within the value are retained
74 Inside double quotes, double quote `"` and backslash `\` characters
75 must be escaped: use `\"` for `"` and `\\` for `\`.
77 The following escape sequences (beside `\"` and `\\`) are recognized:
78 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
79 and `\b` for backspace (BS). Other char escape sequences (including octal
80 escape sequences) are invalid.
86 The `include` and `includeIf` sections allow you to include config
87 directives from another source. These sections behave identically to
88 each other with the exception that `includeIf` sections may be ignored
89 if their condition does not evaluate to true; see "Conditional includes"
92 You can include a config file from another by setting the special
93 `include.path` (or `includeIf.*.path`) variable to the name of the file
94 to be included. The variable takes a pathname as its value, and is
95 subject to tilde expansion. These variables can be given multiple times.
97 The contents of the included file are inserted immediately, as if they
98 had been found at the location of the include directive. If the value of the
99 variable is a relative path, the path is considered to
100 be relative to the configuration file in which the include directive
101 was found. See below for examples.
106 You can include a config file from another conditionally by setting a
107 `includeIf.<condition>.path` variable to the name of the file to be
110 The condition starts with a keyword followed by a colon and some data
111 whose format and meaning depends on the keyword. Supported keywords
116 The data that follows the keyword `gitdir:` is used as a glob
117 pattern. If the location of the .git directory matches the
118 pattern, the include condition is met.
120 The .git location may be auto-discovered, or come from `$GIT_DIR`
121 environment variable. If the repository is auto discovered via a .git
122 file (e.g. from submodules, or a linked worktree), the .git location
123 would be the final location where the .git directory is, not where the
126 The pattern can contain standard globbing wildcards and two additional
127 ones, `**/` and `/**`, that can match multiple path components. Please
128 refer to linkgit:gitignore[5] for details. For convenience:
130 * If the pattern starts with `~/`, `~` will be substituted with the
131 content of the environment variable `HOME`.
133 * If the pattern starts with `./`, it is replaced with the directory
134 containing the current config file.
136 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
137 will be automatically prepended. For example, the pattern `foo/bar`
138 becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
140 * If the pattern ends with `/`, `**` will be automatically added. For
141 example, the pattern `foo/` becomes `foo/**`. In other words, it
142 matches "foo" and everything inside, recursively.
145 This is the same as `gitdir` except that matching is done
146 case-insensitively (e.g. on case-insensitive file systems)
149 The data that follows the keyword `onbranch:` is taken to be a
150 pattern with standard globbing wildcards and two additional
151 ones, `**/` and `/**`, that can match multiple path components.
152 If we are in a worktree where the name of the branch that is
153 currently checked out matches the pattern, the include condition
156 If the pattern ends with `/`, `**` will be automatically added. For
157 example, the pattern `foo/` becomes `foo/**`. In other words, it matches
158 all branches that begin with `foo/`. This is useful if your branches are
159 organized hierarchically and you would like to apply a configuration to
160 all the branches in that hierarchy.
162 `hasconfig:remote.*.url:`::
163 The data that follows this keyword is taken to
164 be a pattern with standard globbing wildcards and two
165 additional ones, `**/` and `/**`, that can match multiple
166 components. The first time this keyword is seen, the rest of
167 the config files will be scanned for remote URLs (without
168 applying any values). If there exists at least one remote URL
169 that matches this pattern, the include condition is met.
171 Files included by this option (directly or indirectly) are not allowed
172 to contain remote URLs.
174 Note that unlike other includeIf conditions, resolving this condition
175 relies on information that is not yet known at the point of reading the
176 condition. A typical use case is this option being present as a
177 system-level or global-level config, and the remote URL being in a
178 local-level config; hence the need to scan ahead when resolving this
179 condition. In order to avoid the chicken-and-egg problem in which
180 potentially-included files can affect whether such files are potentially
181 included, Git breaks the cycle by prohibiting these files from affecting
182 the resolution of these conditions (thus, prohibiting them from
183 declaring remote URLs).
185 As for the naming of this keyword, it is for forwards compatibiliy with
186 a naming scheme that supports more variable-based include conditions,
187 but currently Git only supports the exact keyword described above.
189 A few more notes on matching via `gitdir` and `gitdir/i`:
191 * Symlinks in `$GIT_DIR` are not resolved before matching.
193 * Both the symlink & realpath versions of paths will be matched
194 outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
195 /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
198 This was not the case in the initial release of this feature in
199 v2.13.0, which only matched the realpath version. Configuration that
200 wants to be compatible with the initial release of this feature needs
201 to either specify only the realpath version, or both versions.
203 * Note that "../" is not special and will match literally, which is
204 unlikely what you want.
212 ; Don't trust file modes
217 external = /usr/local/bin/diff-wrapper
222 merge = refs/heads/devel
226 gitProxy="ssh" for "kernel.org"
227 gitProxy=default-proxy ; for the rest
230 path = /path/to/foo.inc ; include by absolute path
231 path = foo.inc ; find "foo.inc" relative to the current file
232 path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
234 ; include if $GIT_DIR is /path/to/foo/.git
235 [includeIf "gitdir:/path/to/foo/.git"]
236 path = /path/to/foo.inc
238 ; include for all repositories inside /path/to/group
239 [includeIf "gitdir:/path/to/group/"]
240 path = /path/to/foo.inc
242 ; include for all repositories inside $HOME/to/group
243 [includeIf "gitdir:~/to/group/"]
244 path = /path/to/foo.inc
246 ; relative paths are always relative to the including
247 ; file (if the condition is true); their location is not
248 ; affected by the condition
249 [includeIf "gitdir:/path/to/group/"]
252 ; include only if we are in a worktree where foo-branch is
253 ; currently checked out
254 [includeIf "onbranch:foo-branch"]
257 ; include only if a remote with the given URL exists (note
258 ; that such a URL may be provided later in a file or in a
259 ; file read after this file is read, as seen in this example)
260 [includeIf "hasconfig:remote.*.url:https://example.com/**"]
263 url = https://example.com/git
269 Values of many variables are treated as a simple string, but there
270 are variables that take values of specific types and there are rules
271 as to how to spell them.
275 When a variable is said to take a boolean value, many
276 synonyms are accepted for 'true' and 'false'; these are all
279 true;; Boolean true literals are `yes`, `on`, `true`,
280 and `1`. Also, a variable defined without `= <value>`
283 false;; Boolean false literals are `no`, `off`, `false`,
284 `0` and the empty string.
286 When converting a value to its canonical form using the `--type=bool` type
287 specifier, 'git config' will ensure that the output is "true" or
288 "false" (spelled in lowercase).
291 The value for many variables that specify various sizes can
292 be suffixed with `k`, `M`,... to mean "scale the number by
293 1024", "by 1024x1024", etc.
296 The value for a variable that takes a color is a list of
297 colors (at most two, one for foreground and one for background)
298 and attributes (as many as you want), separated by spaces.
300 The basic colors accepted are `normal`, `black`, `red`, `green`,
301 `yellow`, `blue`, `magenta`, `cyan`, `white` and `default`. The first
302 color given is the foreground; the second is the background. All the
303 basic colors except `normal` and `default` have a bright variant that can
304 be specified by prefixing the color with `bright`, like `brightred`.
306 The color `normal` makes no change to the color. It is the same as an
307 empty string, but can be used as the foreground color when specifying a
308 background color alone (for example, "normal red").
310 The color `default` explicitly resets the color to the terminal default,
311 for example to specify a cleared background. Although it varies between
312 terminals, this is usually not the same as setting to "white black".
314 Colors may also be given as numbers between 0 and 255; these use ANSI
315 256-color mode (but note that not all terminals may support this). If
316 your terminal supports it, you may also specify 24-bit RGB values as
319 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
320 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
321 The position of any attributes with respect to the colors
322 (before, after, or in between), doesn't matter. Specific attributes may
323 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
326 The pseudo-attribute `reset` resets all colors and attributes before
327 applying the specified coloring. For example, `reset green` will result
328 in a green foreground and default background without any active
331 An empty color string produces no color effect at all. This can be used
332 to avoid coloring specific elements without disabling color entirely.
334 For git's pre-defined color slots, the attributes are meant to be reset
335 at the beginning of each item in the colored output. So setting
336 `color.decorate.branch` to `black` will paint that branch name in a
337 plain `black`, even if the previous thing on the same output line (e.g.
338 opening parenthesis before the list of branch names in `log --decorate`
339 output) is set to be painted with `bold` or some other attribute.
340 However, custom log formats may do more complicated and layered
341 coloring, and the negated forms may be useful there.
344 A variable that takes a pathname value can be given a
345 string that begins with "`~/`" or "`~user/`", and the usual
346 tilde expansion happens to such a string: `~/`
347 is expanded to the value of `$HOME`, and `~user/` to the
348 specified user's home directory.
350 If a path starts with `%(prefix)/`, the remainder is interpreted as a
351 path relative to Git's "runtime prefix", i.e. relative to the location
352 where Git itself was installed. For example, `%(prefix)/bin/` refers to
353 the directory in which the Git executable itself lives. If Git was
354 compiled without runtime prefix support, the compiled-in prefix will be
355 substituted instead. In the unlikely event that a literal path needs to
356 be specified that should _not_ be expanded, it needs to be prefixed by
357 `./`, like so: `./%(prefix)/bin`.
363 Note that this list is non-comprehensive and not necessarily complete.
364 For command-specific variables, you will find a more detailed description
365 in the appropriate manual page.
367 Other git-related tools may and do use their own variables. When
368 inventing new variables for use in your own tool, make sure their
369 names do not conflict with those that are used by Git itself and
370 other popular tools, and describe them in your documentation.
372 include::config/advice.txt[]
374 include::config/core.txt[]
376 include::config/add.txt[]
378 include::config/alias.txt[]
380 include::config/am.txt[]
382 include::config/apply.txt[]
384 include::config/blame.txt[]
386 include::config/branch.txt[]
388 include::config/browser.txt[]
390 include::config/checkout.txt[]
392 include::config/clean.txt[]
394 include::config/clone.txt[]
396 include::config/color.txt[]
398 include::config/column.txt[]
400 include::config/commit.txt[]
402 include::config/commitgraph.txt[]
404 include::config/credential.txt[]
406 include::config/completion.txt[]
408 include::config/diff.txt[]
410 include::config/difftool.txt[]
412 include::config/extensions.txt[]
414 include::config/fastimport.txt[]
416 include::config/feature.txt[]
418 include::config/fetch.txt[]
420 include::config/format.txt[]
422 include::config/filter.txt[]
424 include::config/fsck.txt[]
426 include::config/fsmonitor--daemon.txt[]
428 include::config/gc.txt[]
430 include::config/gitcvs.txt[]
432 include::config/gitweb.txt[]
434 include::config/grep.txt[]
436 include::config/gpg.txt[]
438 include::config/gui.txt[]
440 include::config/guitool.txt[]
442 include::config/help.txt[]
444 include::config/http.txt[]
446 include::config/i18n.txt[]
448 include::config/imap.txt[]
450 include::config/includeif.txt[]
452 include::config/index.txt[]
454 include::config/init.txt[]
456 include::config/instaweb.txt[]
458 include::config/interactive.txt[]
460 include::config/log.txt[]
462 include::config/lsrefs.txt[]
464 include::config/mailinfo.txt[]
466 include::config/mailmap.txt[]
468 include::config/maintenance.txt[]
470 include::config/man.txt[]
472 include::config/merge.txt[]
474 include::config/mergetool.txt[]
476 include::config/notes.txt[]
478 include::config/pack.txt[]
480 include::config/pager.txt[]
482 include::config/pretty.txt[]
484 include::config/protocol.txt[]
486 include::config/pull.txt[]
488 include::config/push.txt[]
490 include::config/rebase.txt[]
492 include::config/receive.txt[]
494 include::config/remote.txt[]
496 include::config/remotes.txt[]
498 include::config/repack.txt[]
500 include::config/rerere.txt[]
502 include::config/revert.txt[]
504 include::config/safe.txt[]
506 include::config/sendemail.txt[]
508 include::config/sequencer.txt[]
510 include::config/showbranch.txt[]
512 include::config/sparse.txt[]
514 include::config/splitindex.txt[]
516 include::config/ssh.txt[]
518 include::config/status.txt[]
520 include::config/stash.txt[]
522 include::config/submodule.txt[]
524 include::config/tag.txt[]
526 include::config/tar.txt[]
528 include::config/trace2.txt[]
530 include::config/transfer.txt[]
532 include::config/uploadarchive.txt[]
534 include::config/uploadpack.txt[]
536 include::config/url.txt[]
538 include::config/user.txt[]
540 include::config/versionsort.txt[]
542 include::config/web.txt[]
544 include::config/worktree.txt[]