]> git.ipfire.org Git - thirdparty/git.git/blob - Documentation/config.txt
Merge branch 'ds/grep-doc-updates'
[thirdparty/git.git] / Documentation / config.txt
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
118 The data that follows the keyword `gitdir:` is used as a glob
119 pattern. If the location of the .git directory matches the
120 pattern, the include condition is met.
121 +
122 The .git location may be auto-discovered, or come from `$GIT_DIR`
123 environment variable. If the repository is auto-discovered via a .git
124 file (e.g. from submodules, or a linked worktree), the .git location
125 would be the final location where the .git directory is, not where the
126 .git file is.
127 +
128 The pattern can contain standard globbing wildcards and two additional
129 ones, `**/` and `/**`, that can match multiple path components. Please
130 refer to linkgit:gitignore[5] for details. For convenience:
131
132 * If the pattern starts with `~/`, `~` will be substituted with the
133 content of the environment variable `HOME`.
134
135 * If the pattern starts with `./`, it is replaced with the directory
136 containing the current config file.
137
138 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
139 will be automatically prepended. For example, the pattern `foo/bar`
140 becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
141
142 * If the pattern ends with `/`, `**` will be automatically added. For
143 example, the pattern `foo/` becomes `foo/**`. In other words, it
144 matches "foo" and everything inside, recursively.
145
146 `gitdir/i`::
147 This is the same as `gitdir` except that matching is done
148 case-insensitively (e.g. on case-insensitive file systems)
149
150 `onbranch`::
151 The data that follows the keyword `onbranch:` is taken to be a
152 pattern with standard globbing wildcards and two additional
153 ones, `**/` and `/**`, that can match multiple path components.
154 If we are in a worktree where the name of the branch that is
155 currently checked out matches the pattern, the include condition
156 is met.
157 +
158 If the pattern ends with `/`, `**` will be automatically added. For
159 example, the pattern `foo/` becomes `foo/**`. In other words, it matches
160 all branches that begin with `foo/`. This is useful if your branches are
161 organized hierarchically and you would like to apply a configuration to
162 all the branches in that hierarchy.
163
164 `hasconfig:remote.*.url:`::
165 The data that follows this keyword is taken to
166 be a pattern with standard globbing wildcards and two
167 additional ones, `**/` and `/**`, that can match multiple
168 components. The first time this keyword is seen, the rest of
169 the config files will be scanned for remote URLs (without
170 applying any values). If there exists at least one remote URL
171 that matches this pattern, the include condition is met.
172 +
173 Files included by this option (directly or indirectly) are not allowed
174 to contain remote URLs.
175 +
176 Note that unlike other includeIf conditions, resolving this condition
177 relies on information that is not yet known at the point of reading the
178 condition. A typical use case is this option being present as a
179 system-level or global-level config, and the remote URL being in a
180 local-level config; hence the need to scan ahead when resolving this
181 condition. In order to avoid the chicken-and-egg problem in which
182 potentially-included files can affect whether such files are potentially
183 included, Git breaks the cycle by prohibiting these files from affecting
184 the resolution of these conditions (thus, prohibiting them from
185 declaring remote URLs).
186 +
187 As for the naming of this keyword, it is for forwards compatibility with
188 a naming scheme that supports more variable-based include conditions,
189 but currently Git only supports the exact keyword described above.
190
191 A few more notes on matching via `gitdir` and `gitdir/i`:
192
193 * Symlinks in `$GIT_DIR` are not resolved before matching.
194
195 * Both the symlink & realpath versions of paths will be matched
196 outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
197 /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
198 will match.
199 +
200 This was not the case in the initial release of this feature in
201 v2.13.0, which only matched the realpath version. Configuration that
202 wants to be compatible with the initial release of this feature needs
203 to either specify only the realpath version, or both versions.
204
205 * Note that "../" is not special and will match literally, which is
206 unlikely what you want.
207
208 Example
209 ~~~~~~~
210
211 ----
212 # Core variables
213 [core]
214 ; Don't trust file modes
215 filemode = false
216
217 # Our diff algorithm
218 [diff]
219 external = /usr/local/bin/diff-wrapper
220 renames = true
221
222 [branch "devel"]
223 remote = origin
224 merge = refs/heads/devel
225
226 # Proxy settings
227 [core]
228 gitProxy="ssh" for "kernel.org"
229 gitProxy=default-proxy ; for the rest
230
231 [include]
232 path = /path/to/foo.inc ; include by absolute path
233 path = foo.inc ; find "foo.inc" relative to the current file
234 path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
235
236 ; include if $GIT_DIR is /path/to/foo/.git
237 [includeIf "gitdir:/path/to/foo/.git"]
238 path = /path/to/foo.inc
239
240 ; include for all repositories inside /path/to/group
241 [includeIf "gitdir:/path/to/group/"]
242 path = /path/to/foo.inc
243
244 ; include for all repositories inside $HOME/to/group
245 [includeIf "gitdir:~/to/group/"]
246 path = /path/to/foo.inc
247
248 ; relative paths are always relative to the including
249 ; file (if the condition is true); their location is not
250 ; affected by the condition
251 [includeIf "gitdir:/path/to/group/"]
252 path = foo.inc
253
254 ; include only if we are in a worktree where foo-branch is
255 ; currently checked out
256 [includeIf "onbranch:foo-branch"]
257 path = foo.inc
258
259 ; include only if a remote with the given URL exists (note
260 ; that such a URL may be provided later in a file or in a
261 ; file read after this file is read, as seen in this example)
262 [includeIf "hasconfig:remote.*.url:https://example.com/**"]
263 path = foo.inc
264 [remote "origin"]
265 url = https://example.com/git
266 ----
267
268 Values
269 ~~~~~~
270
271 Values of many variables are treated as a simple string, but there
272 are variables that take values of specific types and there are rules
273 as to how to spell them.
274
275 boolean::
276
277 When a variable is said to take a boolean value, many
278 synonyms are accepted for 'true' and 'false'; these are all
279 case-insensitive.
280
281 true;; Boolean true literals are `yes`, `on`, `true`,
282 and `1`. Also, a variable defined without `= <value>`
283 is taken as true.
284
285 false;; Boolean false literals are `no`, `off`, `false`,
286 `0` and the empty string.
287 +
288 When converting a value to its canonical form using the `--type=bool` type
289 specifier, 'git config' will ensure that the output is "true" or
290 "false" (spelled in lowercase).
291
292 integer::
293 The value for many variables that specify various sizes can
294 be suffixed with `k`, `M`,... to mean "scale the number by
295 1024", "by 1024x1024", etc.
296
297 color::
298 The value for a variable that takes a color is a list of
299 colors (at most two, one for foreground and one for background)
300 and attributes (as many as you want), separated by spaces.
301 +
302 The basic colors accepted are `normal`, `black`, `red`, `green`,
303 `yellow`, `blue`, `magenta`, `cyan`, `white` and `default`. The first
304 color given is the foreground; the second is the background. All the
305 basic colors except `normal` and `default` have a bright variant that can
306 be specified by prefixing the color with `bright`, like `brightred`.
307 +
308 The color `normal` makes no change to the color. It is the same as an
309 empty string, but can be used as the foreground color when specifying a
310 background color alone (for example, "normal red").
311 +
312 The color `default` explicitly resets the color to the terminal default,
313 for example to specify a cleared background. Although it varies between
314 terminals, this is usually not the same as setting to "white black".
315 +
316 Colors may also be given as numbers between 0 and 255; these use ANSI
317 256-color mode (but note that not all terminals may support this). If
318 your terminal supports it, you may also specify 24-bit RGB values as
319 hex, like `#ff0ab3`.
320 +
321 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
322 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
323 The position of any attributes with respect to the colors
324 (before, after, or in between), doesn't matter. Specific attributes may
325 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
326 `no-ul`, etc).
327 +
328 The pseudo-attribute `reset` resets all colors and attributes before
329 applying the specified coloring. For example, `reset green` will result
330 in a green foreground and default background without any active
331 attributes.
332 +
333 An empty color string produces no color effect at all. This can be used
334 to avoid coloring specific elements without disabling color entirely.
335 +
336 For git's pre-defined color slots, the attributes are meant to be reset
337 at the beginning of each item in the colored output. So setting
338 `color.decorate.branch` to `black` will paint that branch name in a
339 plain `black`, even if the previous thing on the same output line (e.g.
340 opening parenthesis before the list of branch names in `log --decorate`
341 output) is set to be painted with `bold` or some other attribute.
342 However, custom log formats may do more complicated and layered
343 coloring, and the negated forms may be useful there.
344
345 pathname::
346 A variable that takes a pathname value can be given a
347 string that begins with "`~/`" or "`~user/`", and the usual
348 tilde expansion happens to such a string: `~/`
349 is expanded to the value of `$HOME`, and `~user/` to the
350 specified user's home directory.
351 +
352 If a path starts with `%(prefix)/`, the remainder is interpreted as a
353 path relative to Git's "runtime prefix", i.e. relative to the location
354 where Git itself was installed. For example, `%(prefix)/bin/` refers to
355 the directory in which the Git executable itself lives. If Git was
356 compiled without runtime prefix support, the compiled-in prefix will be
357 substituted instead. In the unlikely event that a literal path needs to
358 be specified that should _not_ be expanded, it needs to be prefixed by
359 `./`, like so: `./%(prefix)/bin`.
360
361
362 Variables
363 ~~~~~~~~~
364
365 Note that this list is non-comprehensive and not necessarily complete.
366 For command-specific variables, you will find a more detailed description
367 in the appropriate manual page.
368
369 Other git-related tools may and do use their own variables. When
370 inventing new variables for use in your own tool, make sure their
371 names do not conflict with those that are used by Git itself and
372 other popular tools, and describe them in your documentation.
373
374 include::config/add.txt[]
375
376 include::config/advice.txt[]
377
378 include::config/alias.txt[]
379
380 include::config/am.txt[]
381
382 include::config/apply.txt[]
383
384 include::config/attr.txt[]
385
386 include::config/blame.txt[]
387
388 include::config/branch.txt[]
389
390 include::config/browser.txt[]
391
392 include::config/bundle.txt[]
393
394 include::config/checkout.txt[]
395
396 include::config/clean.txt[]
397
398 include::config/clone.txt[]
399
400 include::config/color.txt[]
401
402 include::config/column.txt[]
403
404 include::config/commit.txt[]
405
406 include::config/commitgraph.txt[]
407
408 include::config/completion.txt[]
409
410 include::config/core.txt[]
411
412 include::config/credential.txt[]
413
414 include::config/diff.txt[]
415
416 include::config/difftool.txt[]
417
418 include::config/extensions.txt[]
419
420 include::config/fastimport.txt[]
421
422 include::config/feature.txt[]
423
424 include::config/fetch.txt[]
425
426 include::config/filter.txt[]
427
428 include::config/format.txt[]
429
430 include::config/fsck.txt[]
431
432 include::config/fsmonitor--daemon.txt[]
433
434 include::config/gc.txt[]
435
436 include::config/gitcvs.txt[]
437
438 include::config/gitweb.txt[]
439
440 include::config/gpg.txt[]
441
442 include::config/grep.txt[]
443
444 include::config/gui.txt[]
445
446 include::config/guitool.txt[]
447
448 include::config/help.txt[]
449
450 include::config/http.txt[]
451
452 include::config/i18n.txt[]
453
454 include::config/imap.txt[]
455
456 include::config/includeif.txt[]
457
458 include::config/index.txt[]
459
460 include::config/init.txt[]
461
462 include::config/instaweb.txt[]
463
464 include::config/interactive.txt[]
465
466 include::config/log.txt[]
467
468 include::config/lsrefs.txt[]
469
470 include::config/mailinfo.txt[]
471
472 include::config/mailmap.txt[]
473
474 include::config/maintenance.txt[]
475
476 include::config/man.txt[]
477
478 include::config/merge.txt[]
479
480 include::config/mergetool.txt[]
481
482 include::config/notes.txt[]
483
484 include::config/pack.txt[]
485
486 include::config/pager.txt[]
487
488 include::config/pretty.txt[]
489
490 include::config/protocol.txt[]
491
492 include::config/pull.txt[]
493
494 include::config/push.txt[]
495
496 include::config/rebase.txt[]
497
498 include::config/receive.txt[]
499
500 include::config/remote.txt[]
501
502 include::config/remotes.txt[]
503
504 include::config/repack.txt[]
505
506 include::config/rerere.txt[]
507
508 include::config/revert.txt[]
509
510 include::config/safe.txt[]
511
512 include::config/sendemail.txt[]
513
514 include::config/sequencer.txt[]
515
516 include::config/showbranch.txt[]
517
518 include::config/sparse.txt[]
519
520 include::config/splitindex.txt[]
521
522 include::config/ssh.txt[]
523
524 include::config/stash.txt[]
525
526 include::config/status.txt[]
527
528 include::config/submodule.txt[]
529
530 include::config/tag.txt[]
531
532 include::config/tar.txt[]
533
534 include::config/trace2.txt[]
535
536 include::config/transfer.txt[]
537
538 include::config/uploadarchive.txt[]
539
540 include::config/uploadpack.txt[]
541
542 include::config/url.txt[]
543
544 include::config/user.txt[]
545
546 include::config/versionsort.txt[]
547
548 include::config/web.txt[]
549
550 include::config/worktree.txt[]