characters
and `-`, and must start with an alphabetic character.

Whitespace characters surrounding `name`, `=` and `value` are discarded.
Internal whitespace characters within 'value' are retained verbatim.
Comments starting with either `#` or `;` and extending to the end of line
are discarded.  A line that defines a value can be continued to the next
line by ending it with a backslash (`\`);  the backslash and the end-of-line
characters are discarded.

If `value` needs to contain leading or trailing whitespace characters,
it must be enclosed in double quotation marks (`"`).  Inside double quotation
marks, double quote (`"`) and backslash (`\`) characters must be escaped:
use `\"` for `"` and `\\` for `\`.

The following escape sequences (beside `\"` and `\\`) are recognized:
`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
and `\b` for backspace (BS).  Other char escape sequences (including octal
escape sequences) are invalid.


Includes
~~~~~~~~

The `include` and `includeIf` sections allow you to include config
directives from another source. These sections behave identically to
each other with the exception that `includeIf` sections may be ignored
if their condition does not evaluate to true; see "Conditional includes"
below.

You can include a config file from another by setting the special
`include.path` (or `includeIf.*.path`) variable to the name of the file
to be included. The variable takes a pathname as its value, and is
subject to tilde expansion. These variables can be given multiple times.

The contents of the included file are inserted immediately, as if they
had been found at the location of the include directive. If the value of the
variable is a relative path, the path is considered to
be relative to the configuration file in which the include directive
was found.  See below for examples.

Conditional includes
~~~~~~~~~~~~~~~~~~~~

You can conditionally include a config file from another by setting an
`includeIf.<condition>.path` variable to the name of the file to be
included.

The condition starts with a keyword followed by a colon and some data
whose format and meaning depends on the keyword. Supported keywords
are:

`gitdir`::

	The data that follows the keyword `gitdir:` is used as a glob
	pattern. If the location of the .git directory matches the
	pattern, the include condition is met.
+
The .git location may be auto-discovered, or come from `$GIT_DIR`
environment variable. If the repository is auto-discovered via a .git
file (e.g. from submodules, or a linked worktree), the .git location
would be the final location where the .git directory is, not where the
.git file is.
+
The pattern can contain standard globbing wildcards and two additional
ones, `**/` and `/**`, that can match multiple path components. Please
refer to linkgit:gitignore[5] for details. For convenience:

 * If the pattern starts with `~/`, `~` will be substituted with the
   content of the environment variable `HOME`.

 * If the pattern starts with `./`, it is replaced with the directory
   containing the current config file.

 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
   will be automatically prepended. For example, the pattern `foo/bar`
   becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.

 * If the pattern ends with `/`, `**` will be automatically added. For
   example, the pattern `foo/` becomes `foo/**`. In other words, it
   matches "foo" and everything inside, recursively.

`gitdir/i`::
	This is the same as `gitdir` except that matching is done
	case-insensitively (e.g. on case-insensitive file systems)

`onbranch`::
	The data that follows the keyword `onbranch:` is taken to be a
	pattern with standard globbing wildcards and two additional
	ones, `**/` and `/**`, that can match multiple path components.
	If we are in a worktree where the name of the branch that is
	currently checked out matches the pattern, the include condition
	is met.
+
If the pattern ends with