core.txt

core.fileMode::
	Tells Git if the executable bit of files in the working tree
	is to be honored.
+
Some filesystems lose the executable bit when a file that is
marked as executable is checked out, or checks out a
non-executable file with executable bit on.
linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem
to see if it handles the executable bit correctly
and this variable is automatically set as necessary.
+
A repository, however, may be on a filesystem that handles
the filemode correctly, and this variable is set to 'true'
when created, but later may be made accessible from another
environment that loses the filemode (e.g. exporting ext4 via
CIFS mount, visiting a Cygwin created repository with
Git for Windows or Eclipse).
In such a case it may be necessary to set this variable to 'false'.
See linkgit:git-update-index[1].
+
The default is true (when core.filemode is not specified in the config file).

core.hideDotFiles::
	(Windows-only) If true, mark newly-created directories and files whose
	name starts with a dot as hidden.  If 'dotGitOnly', only the `.git/`
	directory is hidden, but no other files starting with a dot.  The
	default mode is 'dotGitOnly'.

core.ignoreCase::
	Internal variable which enables various workarounds to enable
	Git to work better on filesystems that are not case sensitive,
	like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing
	finds "makefile" when Git expects "Makefile", Git will assume
	it is really the same file, and continue to remember it as
	"Makefile".
+
The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignoreCase true if appropriate when the repository
is created.
+
Git relies on the proper configuration of this variable for your operating
and file system. Modifying this value may result in unexpected behavior.

core.precomposeUnicode::
	This option is only used by Mac OS implementation of Git.
	When core.precomposeUnicode=true, Git reverts the unicode decomposition
	of filenames done by Mac OS. This is useful when sharing a repository
	between Mac OS and Linux or Windows.
	(Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).
	When false, file names are handled fully transparent by Git,
	which is backward compatible with older versions of Git.

core.protectHFS::
	If set to true, do not allow checkout of paths that would
	be considered equivalent to `.git` on an HFS+ filesystem.
	Defaults to `true` on Mac OS, and `false` elsewhere.

core.protectNTFS::
	If set to true, do not allow checkout of paths that would
	cause problems with the NTFS filesystem, e.g. conflict with
	8.3 "short" names.
	Defaults to `true` on Windows, and `false` elsewhere.

core.fsmonitor::
	If set, this variable contains the pathname of the "fsmonitor"
	hook command.
+
This hook command is used to identify all files that may have changed
since the requested date/time. This information is used to speed up
git by avoiding unnecessary scanning of files that have not changed.
+
See the "fsmonitor-watchman" section of linkgit:githooks[5].
+
Note: The value of this config setting is ignored if the (experimental)
built-in file system monitor is enabled (see `core.useBuiltinFSMonitor`).

core.fsmonitorHookVersion::
	Sets the protocol version to be used when invoking the
	"fsmonitor" hook.
+
There are currently versions 1 and 2. When this is not set,
version 2 will be tried first and if it fails then version 1
will be tried. Version 1 uses a timestamp as input to determine
which files have changes since that time but some monitors
like Watchman have race conditions when used with a timestamp.
Version 2 uses an opaque string so that the monitor can return
something that can be used to determine what files have changed
without race conditions.
+
Note: The value of this config setting is ignored if the
built-in file system monitor is enabled (see `core.useBuiltinFSMonitor`).

core.useBuiltinFSMonitor::
	(EXPERIMENTAL) If set to true, enable the built-in file system monitor
	daemon for this working directory (linkgit:git-fsmonitor--daemon[1]).
+
Like hook-based file system monitors, the built-in file system monitor
can speed up Git commands that need to refresh the Git index
(e.g. `git status`) in a working directory with many files.  The
built-in monitor eliminates the need to install and maintain an
external third-party tool.
+
The built-in file system monitor is currently available only on a
limited set of supported platforms.  Currently, this includes Windows
and MacOS.
+
Note: if this config setting is set to `true`, the values of
`core.fsmonitor` and `core.fsmonitorHookVersion` are ignored.

core.trustctime::
	If false, the ctime differences between the index and the
	working tree are ignored; useful when the inode change time
	is regularly modified by something outside Git (file system
	crawlers and some backup systems).
	See linkgit:git-update-index[1]. True by default.

core.splitIndex::
	If true, the split-index feature of the index will be used.
	See linkgit:git-update-index[1]. False by default.

core.untrackedCache::
	Determines what to do about the untracked cache feature of the
	index. It will be kept, if this variable is unset or set to
	`keep`. It will automatically be added if set to `true`. And
	it will automatically be removed, if set to `false`. Before
	setting it to `true`, you should check that mtime is working
	properly on your system.
	See linkgit:git-update-index[1]. `keep` by default, unless
	`feature.manyFiles` is enabled which sets this setting to
	`true` by default.

core.checkStat::
	When missing or is set to `default`, many fields in the stat
	structure are checked to detect if a file has been modified
	since Git looked at it.  When this configuration variable is
	set to `minimal`, sub-second part of mtime and ctime, the
	uid and gid of the owner of the file, the inode number (and
	the device number, if Git was compiled to use it), are
	excluded from the check among these fields, leaving only the
	whole-second part of mtime (and ctime, if `core.trustCtime`
	is set) and the filesize to be checked.
+
There are implementations of Git that do not leave usable values in
some fields (e.g. JGit); by excluding these fields from the
comparison, the `minimal` mode may help interoperability when the
same repository is used by these other systems at the same time.

core.quotePath::
	Commands that output paths (e.g. 'ls-files', 'diff'), will
	quote "unusual" characters in the pathname by enclosing the
	pathname in double-quotes and escaping those characters with
	backslashes in the same way C escapes control characters (e.g.
	`\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with
	values larger than 0x80 (e.g. octal `\302\265` for "micro" in
	UTF-8).  If this variable is set to false, bytes higher than
	0x80 are not considered "unusual" any more. Double-quotes,
	backslash and control characters are always escaped regardless
	of the setting of this variable.  A simple space character is
	not considered "unusual".  Many commands can output pathnames
	completely verbatim using the `-z` option. The default value
	is true.

core.eol::
	Sets the line ending type to use in the working directory for
	files that are marked as text (either by having the `text`
	attribute set, or by having `text=auto` and Git auto-detecting
	the contents as text).
	Alternatives are 'lf', 'crlf' and 'native', which uses the platform's
	native line ending.  The default value is `native`.  See
	linkgit:gitattributes[5] for more information on end-of-line
	conversion. Note that this value is ignored if `core.autocrlf`
	is set to `true` or `input`.

core.safecrlf::
	If true, makes Git check if converting `CRLF` is reversible when
	end-of-line conversion is active.  Git will verify if a command
	modifies a file in the work tree either directly or indirectly.
	For example, committing a file followed by checking out the
	same file should yield the original file in the work tree.  If
	this is not the case for the current setting of
	`core.autocrlf`, Git will reject the file.  The variable can
	be set to "warn", in which case Git will only warn about an
	irreversible conversion but continue the operation.
+
CRLF conversion bears a slight chance of corrupting data.
When it is enabled, Git will convert CRLF to LF during commit and LF to
CRLF during checkout.  A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by Git.  For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
+
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes.  Right
after committing you still have the original file in your work
tree and this file is not yet corrupted.  You can explicitly tell
Git that this file is binary and Git will handle the file
appropriately.
+
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished.  In both cases CRLFs are removed
in an irreversible way.  For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
+
Note, this safety check does not mean that a checkout will generate a
file identical to the original file for a different setting of
`core.eol` and `core.autocrlf`, but only for the current one.  For
example, a text file with `LF` would be accepted with `core.eol=lf`
and could later be checked out with `core.eol=crlf`, in which case the
resulting file would contain `CRLF`, although the original file
contained `LF`.  However, in both work trees the line endings would be
consistent, that is either all `LF` or all `CRLF`, but never mixed.  A
file with mixed line endings would be reported by the `core.safecrlf`
mechanism.

core.autocrlf::
	Setting this variable to "true" is the same as setting
	the `text` attribute to "auto" on all files and core.eol to "crlf".
	Set to true if you want to have `CRLF` line endings in your
	working directory and the repository has LF line endings.
	This variable can be set to 'input',
	in which case no output conversion is performed.

core.checkRoundtripEncoding::
	A comma and/or whitespace separated list of encodings that Git
	performs UTF-8 round trip checks on if they are used in an
	`working-tree-encoding` attribute (see linkgit:gitattributes[5]).
	The default value is `SHIFT-JIS`.

core.symlinks::
	If false, symbolic links are checked out as small plain files that
	contain the link text. linkgit:git-update-index[1] and
	linkgit:git-add[1] will not change the recorded type to regular
	file. Useful on filesystems like FAT that do not support
	symbolic links.
+
The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.symlinks false if appropriate when the repository
is created.

core.gitProxy::
	A "proxy command" to execute (as 'command host port') instead
	of establishing direct connection to the remote server when
	using the Git protocol for fetching. If the variable value is
	in the "COMMAND for DOMAIN" format, the command is applied only
	on hostnames ending with the specified domain string. This variable
	may be set multiple times and is matched in the given order;
	the first match wins.
+
Can be overridden by the `GIT_PROXY_COMMAND` environment variable
(which always applies universally, without the special "for"
handling).
+
The special string `none` can be used as the proxy command to
specify that no proxy be used for a given domain pattern.
This is useful for excluding servers inside a firewall from
proxy use, while defaulting to a common proxy for external domains.

core.sshCommand::
	If this variable is set, `git fetch` and `git push` will
	use the specified command instead of `ssh` when they need to
	connect to a remote system. The command is in the same form as
	the `GIT_SSH_COMMAND` environment variable and is overridden
	when the environment variable is set.

core.ignoreStat::
	If true, Git will avoid using lstat() calls to detect if files have
	changed by setting the "assume-unchanged" bit for those tracked files
	which it has updated identically in both the index and working tree.
+
When files are modified outside of Git, the user will need to stage
the modified files explicitly (e.g. see 'Examples' section in
linkgit:git-update-index[1]).
Git will not normally detect changes to those files.
+
This is useful on systems where lstat() calls are very slow, such as
CIFS/Microsoft Windows.
+
False by default.

core.preferSymlinkRefs::
	Instead of the default "symref" format for HEAD
	and other symbolic reference files, use symbolic links.
	This is sometimes needed to work with old scripts that
	expect HEAD to be a symbolic link.

core.alternateRefsCommand::
	When advertising tips of available history from an alternate, use the shell to
	execute the specified command instead of linkgit:git-for-each-ref[1]. The
	first argument is the absolute path of the alternate. Output must contain one
	hex object id per line (i.e., the same as produced by `git for-each-ref
	--format='%(objectname)'`).
+
Note that you cannot generally put `git for-each-ref` directly into the config
value, as it does not take a repository path as an argument (but you can wrap
the command above in a shell script).

core.alternateRefsPrefixes::
	When listing references from an alternate, list only references that begin
	with the given prefix. Prefixes match as if they were given as arguments to
	linkgit:git-for-each-ref[1]. To list multiple prefixes, separate them with
	whitespace. If `core.alternateRefsCommand` is set, setting
	`core.alternateRefsPrefixes` has no effect.

core.bare::
	If true this repository is assumed to be 'bare' and has no
	working directory associated with it.  If this is the case a
	number of commands that require a working directory will be
	disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
+
This setting is automatically guessed by linkgit:git-clone[1] or
linkgit:git-init[1] when the repository was created.  By default a
repository that ends in "/.git" is assumed to be not bare (bare =
false), while all other repositories are assumed to be bare (bare
= true).

core.worktree::
	Set the path to the root of the working tree.
	If `GIT_COMMON_DIR` environment variable is set, core.worktree
	is ignored and not used for determining the root of working tree.
	This can be overridden by the `GIT_WORK_TREE` environment
	variable and the `--work-tree` command-line option.
	The value can be an absolute path or relative to the path to
	the .git directory, which is either specified by --git-dir
	or GIT_DIR, or automatically discovered.
	If --git-dir or GIT_DIR is specified but none of
	--work-tree, GIT_WORK_TREE and core.worktree is specified,
	the current working directory is regarded as the top level
	of your working tree.
+
Note that this variable is honored even when set in a configuration
file in a ".git" subdirectory of a directory and its value differs
from the latter directory (e.g. "/path/to/.git/config" has
core.worktree set to "/different/path"), which is most likely a
misconfiguration.  Running Git commands in the "/path/to" directory will
still use "/different/path" as the root of the work tree and can cause
confusion unless you know what you are doing (e.g. you are creating a
read-only snapshot of the same index to a location different from the
repository's usual working tree).

core.logAllRefUpdates::
	Enable the reflog. Updates to a ref <ref> is logged to the file
	"`$GIT_DIR/logs/<ref>`", by appending the new and old
	SHA-1, the date/time and the reason of the update, but
	only when the file exists.  If this configuration
	variable is set to `true`, missing "`$GIT_DIR/logs/<ref>`"
	file is automatically created for branch heads (i.e. under
	`refs/heads/`), remote refs (i.e. under `refs/remotes/`),
	note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
	If it is set to `always`, then a missing reflog is automatically
	created for any ref under `refs/`.
+
This information can be used to determine what commit
was the tip of a branch "2 days ago".
+
This value is true by default in a repository that has
a working directory associated with it, and false by
default in a bare repository.

core.repositoryFormatVersion::
	Internal variable identifying the repository format and layout
	version.

core.sharedRepository::
	When 'group' (or 'true'), the repository is made shareable between
	several users in a group (making sure all the files and objects are
	group-writable). When 'all' (or 'world' or 'everybody'), the
	repository will be readable by all users, additionally to being
	group-shareable. When 'umask' (or 'false'), Git will use permissions
	reported by umask(2). When '0xxx', where '0xxx' is an octal number,
	files in the repository will have this mode value. '0xxx' will override
	user's umask value (whereas the other options will only override
	requested parts of the user's umask value). Examples: '0660' will make
	the repo read/write-able for the owner and group, but inaccessible to
	others (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a
	repository that is group-readable but not group-writable.
	See linkgit:git-init[1]. False by default.

core.warnAmbiguousRefs::
	If true, Git will warn you if the ref name you passed it is ambiguous
	and might match multiple refs in the repository. True by default.

core.compression::
	An integer -1..9, indicating a default compression level.
	-1 is the zlib default. 0 means no compression,
	and 1..9 are various speed/size tradeoffs, 9 being slowest.
	If set, this provides a default to other compression variables,
	such as `core.looseCompression` and `pack.compression`.

core.looseCompression::
	An integer -1..9, indicating the compression level for objects that
	are not in a pack file. -1 is the zlib default. 0 means no
	compression, and 1..9 are various speed/size tradeoffs, 9 being
	slowest.  If not set,  defaults to core.compression.  If that is
	not set,  defaults to 1 (best speed).

core.packedGitWindowSize::
	Number of bytes of a pack file to map into memory in a
	single mapping operation.  Larger window sizes may allow
	your system to process a smaller number of large pack files
	more quickly.  Smaller window sizes will negatively affect
	performance due to increased calls to the operating system's
	memory manager, but may improve performance when accessing
	a large number of large pack files.
+
Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
MiB on 32 bit platforms and 1 GiB on 64 bit platforms.  This should
be reasonable for all users/operating systems.  You probably do
not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.

core.packedGitLimit::
	Maximum number of bytes to map simultaneously into memory
	from pack files.  If Git needs to access more than this many
	bytes at once to complete an operation it will unmap existing
	regions to reclaim virtual address space within the process.
+
Default is 256 MiB on 32 bit platforms and 32 TiB (effectively
unlimited) on 64 bit platforms.
This should be reasonable for all users/operating systems, except on
the largest projects.  You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.

core.deltaBaseCacheLimit::
	Maximum number of bytes per thread to reserve for caching base objects
	that may be referenced by multiple deltified objects.  By storing the
	entire decompressed base objects in a cache Git is able
	to avoid unpacking and decompressing frequently used base
	objects multiple times.
+
Default is 96 MiB on all platforms.  This should be reasonable
for all users/operating systems, except on the largest projects.
You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.

core.bigFileThreshold::
	Files larger than this size are stored deflated, without
	attempting delta compression.  Storing large files without
	delta compression avoids excessive memory usage, at the
	slight expense of increased disk usage. Additionally files
	larger than this size are always treated as binary.
+
Default is 512 MiB on all platforms.  This should be reasonable
for most projects as source code and other text files can still
be delta compressed, but larger binary media files won't be.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.

core.excludesFile::
	Specifies the pathname to the file that contains patterns to
	describe paths that are not meant to be tracked, in addition
	to `.gitignore` (per-directory) and `.git/info/exclude`.
	Defaults to `$XDG_CONFIG_HOME/git/ignore`.
	If `$XDG_CONFIG_HOME` is either not set or empty, `$HOME/.config/git/ignore`
	is used instead. See linkgit:gitignore[5].

core.askPass::
	Some commands (e.g. svn and http interfaces) that interactively
	ask for a password can be told to use an external program given
	via the value of this variable. Can be overridden by the `GIT_ASKPASS`
	environment variable. If not set, fall back to the value of the
	`SSH_ASKPASS` environment variable or, failing that, a simple password
	prompt. The external program shall be given a suitable prompt as
	command-line argument and write the password on its STDOUT.

core.attributesFile::
	In addition to `.gitattributes` (per-directory) and
	`.git/info/attributes`, Git looks into this file for attributes
	(see linkgit:gitattributes[5]). Path expansions are made the same
	way as for `core.excludesFile`. Its default value is
	`$XDG_CONFIG_HOME/git/attributes`. If `$XDG_CONFIG_HOME` is either not
	set or empty, `$HOME/.config/git/attributes` is used instead.

core.hooksPath::
	By default Git will look for your hooks in the
	`$GIT_DIR/hooks` directory. Set this to different path,
	e.g. `/etc/git/hooks`, and Git will try to find your hooks in
	that directory, e.g. `/etc/git/hooks/pre-receive` instead of
	in `$GIT_DIR/hooks/pre-receive`.
+
The path can be either absolute or relative. A relative path is
taken as relative to the directory where the hooks are run (see
the "DESCRIPTION" section of linkgit:githooks[5]).
+
This configuration variable is useful in cases where you'd like to
centrally configure your Git hooks instead of configuring them on a
per-repository basis, or as a more flexible and centralized
alternative to having an `init.templateDir` where you've changed
default hooks.

core.editor::
	Commands such as `commit` and `tag` that let you edit
	messages by launching an editor use the value of this
	variable when it is set, and the environment variable
	`GIT_EDITOR` is not set.  See linkgit:git-var[1].

core.commentChar::
	Commands such as `commit` and `tag` that let you edit
	messages consider a line that begins with this character
	commented, and removes them after the editor returns
	(default '#').
+
If set to "auto", `git-commit` would select a character that is not
the beginning character of any line in existing commit messages.

core.filesRefLockTimeout::
	The length of time, in milliseconds, to retry when trying to
	lock an individual reference. Value 0 means not to retry at
	all; -1 means to try indefinitely. Default is 100 (i.e.,
	retry for 100ms).

core.packedRefsTimeout::
	The length of time, in milliseconds, to retry when trying to
	lock the `packed-refs` file. Value 0 means not to retry at
	all; -1 means to try indefinitely. Default is 1000 (i.e.,
	retry for 1 second).

core.pager::
	Text viewer for use by Git commands (e.g., 'less').  The value
	is meant to be interpreted by the shell.  The order of preference
	is the `$GIT_PAGER` environment variable, then `core.pager`
	configuration, then `$PAGER`, and then the default chosen at
	compile time (usually 'less').
+
When the `LESS` environment variable is unset, Git sets it to `FRX`
(if `LESS` environment variable is set, Git does not change it at
all).  If you want to selectively override Git's default setting
for `LESS`, you can set `core.pager` to e.g. `less -S`.  This will
be passed to the shell by Git, which will translate the final
command to `LESS=FRX less -S`. The environment does not set the
`S` option but the command line does, instructing less to truncate
long lines. Similarly, setting `core.pager` to `less -+F` will
deactivate the `F` option specified by the environment from the
command-line, deactivating the "quit if one screen" behavior of
`less`.  One can specifically activate some flags for particular
commands: for example, setting `pager.blame` to `less -S` enables
line truncation only for `git blame`.
+
Likewise, when the `LV` environment variable is unset, Git sets it
to `-c`.  You can override this setting by exporting `LV` with
another value or setting `core.pager` to `lv +c`.

core.whitespace::
	A comma separated list of common whitespace problems to
	notice.  'git diff' will use `color.diff.whitespace` to
	highlight them, and 'git apply --whitespace=error' will
	consider them as errors.  You can prefix `-` to disable
	any of them (e.g. `-trailing-space`):
+
* `blank-at-eol` treats trailing whitespaces at the end of the line
  as an error (enabled by default).
* `space-before-tab` treats a space character that appears immediately
  before a tab character in the initial indent part of the line as an
  error (enabled by default).
* `indent-with-non-tab` treats a line that is indented with space
  characters instead of the equivalent tabs as an error (not enabled by
  default).
* `tab-in-indent` treats a tab character in the initial indent part of
  the line as an error (not enabled by default).
* `blank-at-eof` treats blank lines added at the end of file as an error
  (enabled by default).
* `trailing-space` is a short-hand to cover both `blank-at-eol` and
  `blank-at-eof`.
* `cr-at-eol` treats a carriage-return at the end of line as
  part of the line terminator, i.e. with it, `trailing-space`
  does not trigger if the character before such a carriage-return
  is not a whitespace (not enabled by default).
* `tabwidth=<n>` tells how many character positions a tab occupies; this
  is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent`
  errors. The default tab width is 8. Allowed values are 1 to 63.

core.fsyncObjectFiles::
	A value indicating the level of effort Git will expend in
	trying to make objects added to the repo durable in the event
	of an unclean system shutdown. This setting currently only
	controls loose objects in the object store, so updates to any
	refs or the index may not be equally durable.
+
* `false` allows data to remain in file system caches according to
  operating system policy, whence it may be lost if the system loses power
  or crashes.
* `true` triggers a data integrity flush for each loose object added to the
  object store. This is the safest setting that is likely to ensure durability
  across all operating systems and file systems that honor the 'fsync' system
  call. However, this setting comes with a significant performance cost on
  common hardware. Git does not currently fsync parent directories for
  newly-added files, so some filesystems may still allow data to be lost on
  system crash.
* `batch` enables an experimental mode that uses interfaces available in some
  operating systems to write loose object data with a minimal set of FLUSH
  CACHE (or equivalent) commands sent to the storage controller. If the
  operating system interfaces are not available, this mode behaves the same as
  `true`. This mode is expected to be as safe as `true` on macOS for repos
  stored on HFS+ or APFS filesystems and on Windows for repos stored on NTFS or
  ReFS.

core.preloadIndex::
	Enable parallel index preload for operations like 'git diff'
+
This can speed up operations like 'git diff' and 'git status' especially
on filesystems like NFS that have weak caching semantics and thus
relatively high IO latencies.  When enabled, Git will do the
index comparison to the filesystem data in parallel, allowing
overlapping IO's.  Defaults to true.

core.fscache::
	Enable additional caching of file system data for some operations.
+
Git for Windows uses this to bulk-read and cache lstat data of entire
directories (instead of doing lstat file by file).

core.longpaths::
	Enable long path (> 260) support for builtin commands in Git for
	Windows. This is disabled by default, as long paths are not supported
	by Windows Explorer, cmd.exe and the Git for Windows tool chain
	(msys, bash, tcl, perl...). Only enable this if you know what you're
	doing and are prepared to live with a few quirks.

core.unsetenvvars::
	Windows-only: comma-separated list of environment variables'
	names that need to be unset before spawning any other process.
	Defaults to `PERL5LIB` to account for the fact that Git for
	Windows insists on using its own Perl interpreter.

core.restrictinheritedhandles::
	Windows-only: override whether spawned processes inherit only standard
	file handles (`stdin`, `stdout` and `stderr`) or all handles. Can be
	`auto`, `true` or `false`. Defaults to `auto`, which means `true` on
	Windows 7 and later, and `false` on older Windows versions.

core.createObject::
	You can set this to 'link', in which case a hardlink followed by
	a delete of the source are used to make sure that object creation
	will not overwrite existing objects.
+
On some file system/operating system combinations, this is unreliable.
Set this config setting to 'rename' there; However, This will remove the
check that makes sure that existing object files will not get overwritten.

core.notesRef::
	When showing commit messages, also show notes which are stored in
	the given ref.  The ref must be fully qualified.  If the given
	ref does not exist, it is not an error but means that no
	notes should be printed.
+
This setting defaults to "refs/notes/commits", and it can be overridden by
the `GIT_NOTES_REF` environment variable.  See linkgit:git-notes[1].

core.commitGraph::
	If true, then git will read the commit-graph file (if it exists)
	to parse the graph structure of commits. Defaults to true. See
	linkgit:git-commit-graph[1] for more information.

core.useReplaceRefs::
	If set to `false`, behave as if the `--no-replace-objects`
	option was given on the command line. See linkgit:git[1] and
	linkgit:git-replace[1] for more information.

core.multiPackIndex::
	Use the multi-pack-index file to track multiple packfiles using a
	single index. See linkgit:git-multi-pack-index[1] for more
	information. Defaults to true.

core.sparseCheckout::
	Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
	for more information.

core.sparseCheckoutCone::
	Enables the "cone mode" of the sparse checkout feature. When the
	sparse-checkout file contains a limited set of patterns, then this
	mode provides significant performance advantages. See
	linkgit:git-sparse-checkout[1] for more information.

core.abbrev::
	Set the length object names are abbreviated to.  If
	unspecified or set to "auto", an appropriate value is
	computed based on the approximate number of packed objects
	in your repository, which hopefully is enough for
	abbreviated object names to stay unique for some time.
	If set to "no", no abbreviation is made and the object names
	are shown in their full length.
	The minimum length is 4.