directory that contains `.gitattributes` is from the path in
question, the lower its precedence).
+ If you wish to affect only a single repository (i.e., to assign
+ attributes to files that are particular to one user's workflow), then
+ attributes should be placed in the `$GIT_DIR/info/attributes` file.
+ Attributes which should be version-controlled and distributed to other
+ repositories (i.e., attributes of interest to all users) should go into
+ `.gitattributes` files.
+
Sometimes you would need to override an setting of an attribute
for a path to `unspecified` state. This can be done by listing
the name of the attribute prefixed with an exclamation point `!`.
converted to LF upon checkin, but there is no conversion done
upon checkout.
+If `core.safecrlf` is set to "true" or "warn", git verifies if
+the conversion is reversible for the current setting of
+`core.autocrlf`. For "true", git rejects irreversible
+conversions; for "warn", git only prints a warning but accepts
+an irreversible conversion. The safety triggers to prevent such
+a conversion done to the files in the work tree, but there are a
+few exceptions. Even though...
+
+- "git add" itself does not touch the files in the work tree, the
+ next checkout would, so the safety triggers;
+
+- "git apply" to update a text file with a patch does touch the files
+ in the work tree, but the operation is about text files and CRLF
+ conversion is about fixing the line ending inconsistencies, so the
+ safety does not trigger;
+
+- "git diff" itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next "git add". To
+ catch potential problems early, safety triggers.
+
`ident`
^^^^^^^
* Patterns read from the file specified by the configuration
variable 'core.excludesfile'.
+ Which file to place a pattern in depends on how the pattern is meant to
+ be used. Patterns which should be version-controlled and distributed to
+ other repositories via clone (i.e., files that all developers will want
+ to ignore) should go into a `.gitignore` file. Patterns which are
+ specific to a particular repository but which do not need to be shared
+ with other related repositories (e.g., auxiliary files that live inside
+ the repository but are specific to one user's workflow) should go into
+ the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to
+ ignore in all situations (e.g., backup or temporary files generated by
+ the user's editor of choice) generally go into a file specified by
+ `core.excludesfile` in the user's `~/.gitconfig`.
+
The underlying git plumbing tools, such as
linkgit:git-ls-files[1] and linkgit:git-read-tree[1], read
`gitignore` patterns specified by command-line options, or from
included again. If a negated pattern matches, this will
override lower precedence patterns sources.
+ - If the pattern ends with a slash, it is removed for the
+ purpose of the following description, but it would only find
+ a match with a directory. In other words, `foo/` will match a
+ directory `foo` and paths underneath it, but will not match a
+ regular file or a symbolic link `foo` (this is consistent
+ with the way how pathspec works in general in git).
+
- If the pattern does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
pathname without leading directories.