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 `/`, `**` will be automatically added. For
example, the pattern `foo/` becomes `foo/**`. In other words, it matches
all branches that begin with `foo/`. This is useful if your branches are
organized hierarchically and you would like to apply a configuration to
all the branches in that hierarchy.

`hasconfig:remote.*.url:`::
	The data that follows this keyword is taken to
	be a pattern with standard globbing wildcards and two
	additional ones, `**/` and `/**`, that can match multiple
	components. The first time this keyword is seen, the rest of
	the config files will be scanned for remote URLs (without
	applying any values). If there exists at least one remote URL
	that matches this pattern, the include condition is met.
+
Files included by this option (directly or indirectly) are not allowed
to contain remote URLs.
+
Note that unlike other includeIf conditions, resolving this condition
relies on information that is not yet known at the point of reading the
condition. A typical use case is this option being present as a
system-level or global-level config, and the remote URL being in a
local-level config; hence the need to scan ahead when resolving this
condition. In order to avoid the chicken-and-egg problem in which
potentially-included files can affect whether such files are potentially
included, Git breaks the cycle by prohibiting these files from affecting
the resolution of these conditions (thus, prohibiting them from
declaring remote URLs).
+
As for the naming of this keyword, it is for forwards compatibility with
a naming scheme that supports more variable-based include conditions,
but currently Git only supports the exact keyword described above.

A few more notes on matching via `gitdir` and `gitdir/i`:

 * Symlinks in `$GIT_DIR` are not resolved before matching.

 * Both the symlink & realpath versions of paths will be matched
   outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
   /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
   will match.
+
This was not the case in the initial release of this feature in
v2.13.0, which only matched the realpath version. Configuration that
wants to be compatible with the initial release of this feature needs
to either specify only the realpath version, or both versions.

 * Note that "../" is not special and will match literally, which is
   unlikely what you want.

Example
~~~~~~~

----
# Core variables
[core]
	; Don't trust file modes
	filemode = false

# Our diff algorithm
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

[branch "devel"]
	remote = origin
	merge = refs/heads/devel

# Proxy settings
[core]
	gitProxy="ssh" for "kernel.org"
	gitProxy=default-proxy ; for the rest

[include]
	path = /path/to/foo.inc ; include by absolute path
	path = foo.inc ; find "foo.inc" relative to the current file
	path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory

; include if $GIT_DIR is /path/to/foo/.git
[includeIf "gitdir:/path/to/foo/.git"]
	path = /path/to/foo.inc