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`, or 12-bit RGB values like `#f1b`, which is
 320 equivalent to the 24-bit color `#ff11bb`.
 321 +
 322 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
 323 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
 324 The position of any attributes with respect to the colors
 325 (before, after, or in between), doesn't matter. Specific attributes may
 326 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
 327 `no-ul`, etc).
 328 +
 329 The pseudo-attribute `reset` resets all colors and attributes before
 330 applying the specified coloring. For example, `reset green` will result
 331 in a green foreground and default background without any active
 332 attributes.
 333 +
 334 An empty color string produces no color effect at all. This can be used
 335 to avoid coloring specific elements without disabling color entirely.
 336 +
 337 For git's pre-defined color slots, the attributes are meant to be reset
 338 at the beginning of each item in the colored output. So setting
 339 `color.decorate.branch` to `black` will paint that branch name in a
 340 plain `black`, even if the previous thing on the same output line (e.g.
 341 opening parenthesis before the list of branch names in `log --decorate`
 342 output) is set to be painted with `bold` or some other attribute.
 343 However, custom log formats may do more complicated and layered
 344 coloring, and the negated forms may be useful there.
 345
 346 pathname::
 347         A variable that takes a pathname value can be given a
 348         string that begins with "`~/`" or "`~user/`", and the usual
 349         tilde expansion happens to such a string: `~/`
 350         is expanded to the value of `$HOME`, and `~user/` to the
 351         specified user's home directory.
 352 +
 353 If a path starts with `%(prefix)/`, the remainder is interpreted as a
 354 path relative to Git's "runtime prefix", i.e. relative to the location
 355 where Git itself was installed. For example, `%(prefix)/bin/` refers to
 356 the directory in which the Git executable itself lives. If Git was
 357 compiled without runtime prefix support, the compiled-in prefix will be
 358 substituted instead. In the unlikely event that a literal path needs to
 359 be specified that should _not_ be expanded, it needs to be prefixed by
 360 `./`, like so: `./%(prefix)/bin`.
 361
 362
 363 Variables
 364 ~~~~~~~~~
 365
 366 Note that this list is non-comprehensive and not necessarily complete.
 367 For command-specific variables, you will find a more detailed description
 368 in the appropriate manual page.
 369
 370 Other git-related tools may and do use their own variables.  When
 371 inventing new variables for use in your own tool, make sure their
 372 names do not conflict with those that are used by Git itself and
 373 other popular tools, and describe them in your documentation.
 374
 375 include::config/add.txt[]
 376
 377 include::config/advice.txt[]
 378
 379 include::config/alias.txt[]
 380
 381 include::config/am.txt[]
 382
 383 include::config/apply.txt[]
 384
 385 include::config/attr.txt[]
 386
 387 include::config/bitmap-pseudo-merge.txt[]
 388
 389 include::config/blame.txt[]
 390
 391 include::config/branch.txt[]
 392
 393 include::config/browser.txt[]
 394
 395 include::config/bundle.txt[]
 396
 397 include::config/checkout.txt[]
 398
 399 include::config/clean.txt[]
 400
 401 include::config/clone.txt[]
 402
 403 include::config/color.txt[]
 404
 405 include::config/column.txt[]
 406
 407 include::config/commit.txt[]
 408
 409 include::config/commitgraph.txt[]
 410
 411 include::config/completion.txt[]
 412
 413 include::config/core.txt[]
 414
 415 include::config/credential.txt[]
 416
 417 include::config/diff.txt[]
 418
 419 include::config/difftool.txt[]
 420
 421 include::config/extensions.txt[]
 422
 423 include::config/fastimport.txt[]
 424
 425 include::config/feature.txt[]
 426
 427 include::config/fetch.txt[]
 428
 429 include::config/filter.txt[]
 430
 431 include::config/format.txt[]
 432
 433 include::config/fsck.txt[]
 434
 435 include::config/fsmonitor--daemon.txt[]
 436
 437 include::config/gc.txt[]
 438
 439 include::config/gitcvs.txt[]
 440
 441 include::config/gitweb.txt[]
 442
 443 include::config/gpg.txt[]
 444
 445 include::config/grep.txt[]
 446
 447 include::config/gui.txt[]
 448
 449 include::config/guitool.txt[]
 450
 451 include::config/help.txt[]
 452
 453 include::config/http.txt[]
 454
 455 include::config/i18n.txt[]
 456
 457 include::config/imap.txt[]
 458
 459 include::config/includeif.txt[]
 460
 461 include::config/index.txt[]
 462
 463 include::config/init.txt[]
 464
 465 include::config/instaweb.txt[]
 466
 467 include::config/interactive.txt[]
 468
 469 include::config/log.txt[]
 470
 471 include::config/lsrefs.txt[]
 472
 473 include::config/mailinfo.txt[]
 474
 475 include::config/mailmap.txt[]
 476
 477 include::config/maintenance.txt[]
 478
 479 include::config/man.txt[]
 480
 481 include::config/merge.txt[]
 482
 483 include::config/mergetool.txt[]
 484
 485 include::config/notes.txt[]
 486
 487 include::config/pack.txt[]
 488
 489 include::config/pager.txt[]
 490
 491 include::config/pretty.txt[]
 492
 493 include::config/promisor.txt[]
 494
 495 include::config/protocol.txt[]
 496
 497 include::config/pull.txt[]
 498
 499 include::config/push.txt[]
 500
 501 include::config/rebase.txt[]
 502
 503 include::config/receive.txt[]
 504
 505 include::config/reftable.txt[]
 506
 507 include::config/remote.txt[]
 508
 509 include::config/remotes.txt[]
 510
 511 include::config/repack.txt[]
 512
 513 include::config/rerere.txt[]
 514
 515 include::config/revert.txt[]
 516
 517 include::config/safe.txt[]
 518
 519 include::config/sendemail.txt[]
 520
 521 include::config/sequencer.txt[]
 522
 523 include::config/showbranch.txt[]
 524
 525 include::config/sparse.txt[]
 526
 527 include::config/splitindex.txt[]
 528
 529 include::config/ssh.txt[]
 530
 531 include::config/stash.txt[]
 532
 533 include::config/status.txt[]
 534
 535 include::config/submodule.txt[]
 536
 537 include::config/tag.txt[]
 538
 539 include::config/tar.txt[]
 540
 541 include::config/trace2.txt[]
 542
 543 include::config/transfer.txt[]
 544
 545 include::config/uploadarchive.txt[]
 546
 547 include::config/uploadpack.txt[]
 548
 549 include::config/url.txt[]
 550
 551 include::config/user.txt[]
 552
 553 include::config/versionsort.txt[]
 554
 555 include::config/web.txt[]
 556
 557 include::config/worktree.txt[]