Raw
1 CONFIGURATION FILE
2 ------------------
3
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.
12
13 The configuration variables are used by both the Git plumbing
14 and the porcelain commands. 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
20 multivalued.
21
22 Syntax
23 ~~~~~~
24
25 The syntax is fairly flexible and permissive. Whitespace characters,
26 which in this context are the space character (SP) and the horizontal
27 tabulation (HT), are mostly ignored. The '#' and ';' characters begin
28 comments to the end of line. Blank lines are ignored.
29
30 The file consists of sections and variables. A section begins with
31 the name of the section in square brackets and continues until the next
32 section begins. Section names are case-insensitive. Only alphanumeric
33 characters, `-` and `.` are allowed in section names. Each variable
34 must belong to some section, which means that there must be a section
35 header before the first setting of a variable.
36
37 Sections can be further divided into subsections. To begin a subsection
38 put its name in double quotes, separated by space from the section name,
39 in the section header, like in the example below:
40
41 --------
42 [section "subsection"]
43
44 --------
45
46 Subsection names are case sensitive and can contain any characters except
47 newline and the null byte. Doublequote `"` and backslash can be included
48 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
49 other characters are dropped when reading; for example, `\t` is read as
50 `t` and `\0` is read as `0`. Section headers cannot span multiple lines.
51 Variables may belong directly to a section or to a given subsection. You
52 can have `[section]` if you have `[section "subsection"]`, but you don't
53 need to.
54
55 There is also a deprecated `[section.subsection]` syntax. With this
56 syntax, the subsection name is converted to lower-case and is also
57 compared case sensitively. These subsection names follow the same
58 restrictions as section names.
59
60 All the other lines (and the remainder of the line after the section
61 header) are recognized as setting variables, in the form
62 'name = value' (or just 'name', which is a short-hand to say that
63 the variable is the boolean "true").
64 The variable names are case-insensitive, allow only alphanumeric characters
65 and `-`, and must start with an alphabetic character.
66
67 Whitespace characters surrounding `name`, `=` and `value` are discarded.
68 Internal whitespace characters within 'value' are retained verbatim.
69 Comments starting with either `#` or `;` and extending to the end of line
70 are discarded. A line that defines a value can be continued to the next
71 line by ending it with a backslash (`\`); the backslash and the end-of-line
72 characters are discarded.
73
74 If `value` needs to contain leading or trailing whitespace characters,
75 it must be enclosed in double quotation marks (`"`). Inside double quotation
76 marks, double quote (`"`) and backslash (`\`) characters must be escaped:
77 use `\"` for `"` and `\\` for `\`.
78
79 The following escape sequences (beside `\"` and `\\`) are recognized:
80 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
81 and `\b` for backspace (BS). Other char escape sequences (including octal
82 escape sequences) are invalid.
83
84
85 Includes
86 ~~~~~~~~
87
88 The `include` and `includeIf` sections allow you to include config
89 directives from another source. These sections behave identically to
90 each other with the exception that `includeIf` sections may be ignored
91 if their condition does not evaluate to true; see "Conditional includes"
92 below.
93
94 You can include a config file from another by setting the special
95 `include.path` (or `includeIf.*.path`) variable to the name of the file
96 to be included. The variable takes a pathname as its value, and is
97 subject to tilde expansion. These variables can be given multiple times.
98
99 The contents of the included file are inserted immediately, as if they
100 had been found at the location of the include directive. If the value of the
101 variable is a relative path, the path is considered to
102 be relative to the configuration file in which the include directive
103 was found. See below for examples.
104
105 Conditional includes
106 ~~~~~~~~~~~~~~~~~~~~
107
108 You can conditionally include a config file from another by setting an
109 `includeIf.<condition>.path` variable to the name of the file to be
110 included.
111
112 The condition starts with a keyword followed by a colon and some data
113 whose format and meaning depends on the keyword. Supported keywords
114 are:
115
116 `gitdir`::
117 The data that follows the keyword `gitdir` and a colon is used as a glob
118 pattern. If the location of the .git directory matches the
119 pattern, the include condition is met.
120 +
121 The .git location may be auto-discovered, or come from `$GIT_DIR`
122 environment variable. If the repository is auto-discovered via a .git
123 file (e.g. from submodules, or a linked worktree), the .git location
124 would be the final location where the .git directory is, not where the
125 .git file is.
126 +
127 The pattern can contain standard globbing wildcards and two additional
128 ones, `**/` and `/**`, that can match multiple path components. Please
129 refer to linkgit:gitignore[5] for details. For convenience:
130
131 * If the pattern starts with `~/`, `~` will be substituted with the
132 content of the environment variable `HOME`.
133
134 * If the pattern starts with `./`, it is replaced with the directory
135 containing the current config file.
136
137 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
138 will be automatically prepended. For example, the pattern `foo/bar`
139 becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
140
141 * If the pattern ends with `/`, `**` will be automatically added. For
142 example, the pattern `foo/` becomes `foo/**`. In other words, it
143 matches "foo" and everything inside, recursively.
144
145 `gitdir/i`::
146 This is the same as `gitdir` except that matching is done
147 case-insensitively (e.g. on case-insensitive file systems)
148
149 `worktree`::
150 The data that follows the keyword `worktree` and a colon is used as a
151 glob pattern. If the working directory of the current worktree matches
152 the pattern, the include condition is met.
153 +
154 The worktree location is the path where files are checked out (as returned
155 by `git rev-parse --show-toplevel`). This is different from `gitdir`, which
156 matches the `.git` directory path. In a linked worktree, the worktree path
157 is the directory where that worktree's files are located, not the main
158 repository's `.git` directory.
159 +
160 The pattern uses the same glob syntax as `gitdir` (including `~/`, `./`,
161 `**/`, and trailing-`/` prefix matching). This condition will never match
162 in a bare repository (which has no worktree).
163 +
164 Unlike `gitdir`, the `worktree` condition currently matches only the
165 realpath-resolved worktree location. If the working tree was entered via a
166 symbolic link, a pattern that uses the symbolic-link spelling may not match;
167 use the real path instead.
168 +
169 This is useful when you want to apply configuration based on where the
170 working tree is located on the filesystem. For example, a contributor who
171 works on the same project both personally and as an employee can use
172 different `user.name` and `user.email` values depending on which directory
173 the worktree is checked out under:
174 +
175 ----
176 [includeIf "worktree:/home/user/work/"]
177 path = ~/.config/git/work.inc
178 [includeIf "worktree:/home/user/personal/"]
179 path = ~/.config/git/personal.inc
180 ----
181 +
182 While `extensions.worktreeConfig` (see linkgit:git-worktree[1]) also supports
183 per-worktree configuration, it stores the config inside each repository's
184 `.git/config.worktree` file and requires running `git config --worktree`
185 inside each worktree individually. In contrast, `includeIf "worktree:..."`
186 can be set once in a global or system-level configuration file (e.g.
187 `~/.config/git/config`) and applies to all repositories at once based on
188 their worktree location.
189
190 `worktree/i`::
191 This is the same as `worktree` except that matching is done
192 case-insensitively (e.g. on case-insensitive file systems)
193
194 `onbranch`::
195 The data that follows the keyword `onbranch` and a colon is taken to be a
196 pattern with standard globbing wildcards and two additional
197 ones, `**/` and `/**`, that can match multiple path components.
198 If we are in a worktree where the name of the branch that is
199 currently checked out matches the pattern, the include condition
200 is met.
201 +
202 If the pattern ends with `/`, `**` will be automatically added. For
203 example, the pattern `foo/` becomes `foo/**`. In other words, it matches
204 all branches that begin with `foo/`. This is useful if your branches are
205 organized hierarchically and you would like to apply a configuration to
206 all the branches in that hierarchy.
207
208 `hasconfig:remote.*.url`::
209 The data that follows this keyword and a colon is taken to
210 be a pattern with standard globbing wildcards and two
211 additional ones, `**/` and `/**`, that can match multiple
212 components. The first time this keyword is seen, the rest of
213 the config files will be scanned for remote URLs (without
214 applying any values). If there exists at least one remote URL
215 that matches this pattern, the include condition is met.
216 +
217 Files included by this option (directly or indirectly) are not allowed
218 to contain remote URLs.
219 +
220 Note that unlike other includeIf conditions, resolving this condition
221 relies on information that is not yet known at the point of reading the
222 condition. A typical use case is this option being present as a
223 system-level or global-level config, and the remote URL being in a
224 local-level config; hence the need to scan ahead when resolving this
225 condition. In order to avoid the chicken-and-egg problem in which
226 potentially-included files can affect whether such files are potentially
227 included, Git breaks the cycle by prohibiting these files from affecting
228 the resolution of these conditions (thus, prohibiting them from
229 declaring remote URLs).
230 +
231 As for the naming of this keyword, it is for forwards compatibility with
232 a naming scheme that supports more variable-based include conditions,
233 but currently Git only supports the exact keyword described above.
234
235 A few more notes on matching via `gitdir` and `gitdir/i`:
236
237 * Symlinks in `$GIT_DIR` are not resolved before matching.
238
239 * Both the symlink & realpath versions of paths will be matched
240 outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
241 /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
242 will match.
243 +
244 This was not the case in the initial release of this feature in
245 v2.13.0, which only matched the realpath version. Configuration that
246 wants to be compatible with the initial release of this feature needs
247 to either specify only the realpath version, or both versions.
248
249 * Note that "../" is not special and will match literally, which is
250 unlikely what you want.
251
252 Example
253 ~~~~~~~
254
255 ----
256 # Core variables
257 [core]
258 ; Don't trust file modes
259 filemode = false
260
261 # Our diff algorithm
262 [diff]
263 external = /usr/local/bin/diff-wrapper
264 renames = true
265
266 [branch "devel"]
267 remote = origin
268 merge = refs/heads/devel
269
270 # Proxy settings
271 [core]
272 gitProxy="ssh" for "kernel.org"
273 gitProxy=default-proxy ; for the rest
274
275 [include]
276 path = /path/to/foo.inc ; include by absolute path
277 path = foo.inc ; find "foo.inc" relative to the current file
278 path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
279
280 ; include if $GIT_DIR is /path/to/foo/.git
281 [includeIf "gitdir:/path/to/foo/.git"]
282 path = /path/to/foo.inc
283
284 ; include for all repositories inside /path/to/group
285 [includeIf "gitdir:/path/to/group/"]
286 path = /path/to/foo.inc
287
288 ; include for all repositories inside $HOME/to/group
289 [includeIf "gitdir:~/to/group/"]
290 path = /path/to/foo.inc
291
292 ; include if the worktree is at /path/to/project-build
293 [includeIf "worktree:/path/to/project-build"]
294 path = build-config.inc
295
296 ; include for all worktrees inside /path/to/group
297 [includeIf "worktree:/path/to/group/"]
298 path = group-config.inc
299
300 ; relative paths are always relative to the including
301 ; file (if the condition is true); their location is not
302 ; affected by the condition
303 [includeIf "gitdir:/path/to/group/"]
304 path = foo.inc
305
306 ; include only if we are in a worktree where foo-branch is
307 ; currently checked out
308 [includeIf "onbranch:foo-branch"]
309 path = foo.inc
310
311 ; include only if a remote with the given URL exists (note
312 ; that such a URL may be provided later in a file or in a
313 ; file read after this file is read, as seen in this example)
314 [includeIf "hasconfig:remote.*.url:https://example.com/**"]
315 path = foo.inc
316 [remote "origin"]
317 url = https://example.com/git
318 ----
319
320 Values
321 ~~~~~~
322
323 Values of many variables are treated as a simple string, but there
324 are variables that take values of specific types and there are rules
325 as to how to spell them.
326
327 boolean::
328
329 When a variable is said to take a boolean value, many
330 synonyms are accepted for 'true' and 'false'; these are all
331 case-insensitive.
332 +
333 --
334 true;; Boolean true literals are `yes`, `on`, `true`,
335 and `1`. Also, a variable defined without `= <value>`
336 is taken as true.
337
338 false;; Boolean false literals are `no`, `off`, `false`,
339 `0` and the empty string.
340 --
341 +
342 When converting a value to its canonical form using the `--type=bool` type
343 specifier, 'git config' will ensure that the output is "true" or
344 "false" (spelled in lowercase).
345
346 integer::
347 The value for many variables that specify various sizes can
348 be suffixed with `k`, `M`,... to mean "scale the number by
349 1024", "by 1024x1024", etc.
350
351 color::
352 The value for a variable that takes a color is a list of
353 colors (at most two, one for foreground and one for background)
354 and attributes (as many as you want), separated by spaces.
355 +
356 The basic colors accepted are `normal`, `black`, `red`, `green`,
357 `yellow`, `blue`, `magenta`, `cyan`, `white` and `default`. The first
358 color given is the foreground; the second is the background. All the
359 basic colors except `normal` and `default` have a bright variant that can
360 be specified by prefixing the color with `bright`, like `brightred`.
361 +
362 The color `normal` makes no change to the color. It is the same as an
363 empty string, but can be used as the foreground color when specifying a
364 background color alone (for example, "normal red").
365 +
366 The color `default` explicitly resets the color to the terminal default,
367 for example to specify a cleared background. Although it varies between
368 terminals, this is usually not the same as setting to "white black".
369 +
370 Colors may also be given as numbers between 0 and 255; these use ANSI
371 256-color mode (but note that not all terminals may support this). If
372 your terminal supports it, you may also specify 24-bit RGB values as
373 hex, like `#ff0ab3`, or 12-bit RGB values like `#f1b`, which is
374 equivalent to the 24-bit color `#ff11bb`.
375 +
376 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
377 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
378 The position of any attributes with respect to the colors
379 (before, after, or in between), doesn't matter. Specific attributes may
380 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
381 `no-ul`, etc).
382 +
383 The pseudo-attribute `reset` resets all colors and attributes before
384 applying the specified coloring. For example, `reset green` will result
385 in a green foreground and default background without any active
386 attributes.
387 +
388 An empty color string produces no color effect at all. This can be used
389 to avoid coloring specific elements without disabling color entirely.
390 +
391 For git's pre-defined color slots, the attributes are meant to be reset
392 at the beginning of each item in the colored output. So setting
393 `color.decorate.branch` to `black` will paint that branch name in a
394 plain `black`, even if the previous thing on the same output line (e.g.
395 opening parenthesis before the list of branch names in `log --decorate`
396 output) is set to be painted with `bold` or some other attribute.
397 However, custom log formats may do more complicated and layered
398 coloring, and the negated forms may be useful there.
399
400 pathname::
401 A variable that takes a pathname value can be given a
402 string that begins with "`~/`" or "`~user/`", and the usual
403 tilde expansion happens to such a string: `~/`
404 is expanded to the value of `$HOME`, and `~user/` to the
405 specified user's home directory.
406 +
407 If a path starts with `%(prefix)/`, the remainder is interpreted as a
408 path relative to Git's "runtime prefix", i.e. relative to the location
409 where Git itself was installed. For example, `%(prefix)/bin/` refers to
410 the directory in which the Git executable itself lives. If Git was
411 compiled without runtime prefix support, the compiled-in prefix will be
412 substituted instead. In the unlikely event that a literal path needs to
413 be specified that should _not_ be expanded, it needs to be prefixed by
414 `./`, like so: `./%(prefix)/bin`.
415 +
416 If prefixed with `:(optional)`, the configuration variable is treated
417 as if it does not exist, if the named path does not exist.
418
419 Variables
420 ~~~~~~~~~
421
422 Note that this list is non-comprehensive and not necessarily complete.
423 For command-specific variables, you will find a more detailed description
424 in the appropriate manual page.
425
426 Other git-related tools may and do use their own variables. When
427 inventing new variables for use in your own tool, make sure their
428 names do not conflict with those that are used by Git itself and
429 other popular tools, and describe them in your documentation.
430
431 include::config/add.adoc[]
432
433 include::config/advice.adoc[]
434
435 include::config/alias.adoc[]
436
437 include::config/am.adoc[]
438
439 include::config/apply.adoc[]
440
441 include::config/attr.adoc[]
442
443 include::config/bitmap-pseudo-merge.adoc[]
444
445 include::config/blame.adoc[]
446
447 include::config/branch.adoc[]
448
449 include::config/browser.adoc[]
450
451 include::config/bundle.adoc[]
452
453 include::config/checkout.adoc[]
454
455 include::config/clean.adoc[]
456
457 include::config/clone.adoc[]
458
459 include::config/color.adoc[]
460
461 include::config/column.adoc[]
462
463 include::config/commit.adoc[]
464
465 include::config/commitgraph.adoc[]
466
467 include::config/completion.adoc[]
468
469 include::config/core.adoc[]
470
471 include::config/credential.adoc[]
472
473 include::config/diff.adoc[]
474
475 include::config/difftool.adoc[]
476
477 include::config/extensions.adoc[]
478
479 include::config/fastimport.adoc[]
480
481 include::config/feature.adoc[]
482
483 include::config/fetch.adoc[]
484
485 include::config/filter.adoc[]
486
487 include::config/format.adoc[]
488
489 include::config/fsck.adoc[]
490
491 include::config/fsmonitor--daemon.adoc[]
492
493 include::config/gc.adoc[]
494
495 include::config/gitcvs.adoc[]
496
497 include::config/gitweb.adoc[]
498
499 include::config/gpg.adoc[]
500
501 include::config/grep.adoc[]
502
503 include::config/gui.adoc[]
504
505 include::config/guitool.adoc[]
506
507 include::config/help.adoc[]
508
509 include::config/hook.adoc[]
510
511 include::config/http.adoc[]
512
513 include::config/i18n.adoc[]
514
515 include::config/imap.adoc[]
516
517 include::config/includeif.adoc[]
518
519 include::config/index.adoc[]
520
521 include::config/init.adoc[]
522
523 include::config/instaweb.adoc[]
524
525 include::config/interactive.adoc[]
526
527 include::config/log.adoc[]
528
529 include::config/lsrefs.adoc[]
530
531 include::config/mailinfo.adoc[]
532
533 include::config/mailmap.adoc[]
534
535 include::config/maintenance.adoc[]
536
537 include::config/man.adoc[]
538
539 include::config/merge.adoc[]
540
541 include::config/mergetool.adoc[]
542
543 include::config/notes.adoc[]
544
545 include::config/pack.adoc[]
546
547 include::config/pager.adoc[]
548
549 include::config/pretty.adoc[]
550
551 include::config/promisor.adoc[]
552
553 include::config/protocol.adoc[]
554
555 include::config/pull.adoc[]
556
557 include::config/push.adoc[]
558
559 include::config/rebase.adoc[]
560
561 include::config/receive.adoc[]
562
563 include::config/reftable.adoc[]
564
565 include::config/remote.adoc[]
566
567 include::config/remotes.adoc[]
568
569 include::config/repack.adoc[]
570
571 include::config/replay.adoc[]
572
573 include::config/rerere.adoc[]
574
575 include::config/revert.adoc[]
576
577 include::config/safe.adoc[]
578
579 include::config/sendemail.adoc[]
580
581 include::config/sequencer.adoc[]
582
583 include::config/showbranch.adoc[]
584
585 include::config/sideband.adoc[]
586
587 include::config/sparse.adoc[]
588
589 include::config/splitindex.adoc[]
590
591 include::config/ssh.adoc[]
592
593 include::config/stash.adoc[]
594
595 include::config/status.adoc[]
596
597 include::config/submodule.adoc[]
598
599 include::config/tag.adoc[]
600
601 include::config/tar.adoc[]
602
603 include::config/trace2.adoc[]
604
605 include::config/trailer.adoc[]
606
607 include::config/transfer.adoc[]
608
609 include::config/uploadarchive.adoc[]
610
611 include::config/uploadpack.adoc[]
612
613 include::config/url.adoc[]
614
615 include::config/user.adoc[]
616
617 include::config/versionsort.adoc[]
618
619 include::config/web.adoc[]
620
621 include::config/worktree.adoc[]