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