gitattributes(5)
================
NAME
----
gitattributes - Defining attributes per path
SYNOPSIS
--------
$GIT_DIR/info/attributes, .gitattributes
DESCRIPTION
-----------
A `gitattributes` file is a simple text file that gives
`attributes` to pathnames.
Each line in `gitattributes` file is of form:
pattern attr1 attr2 ...
That is, a pattern followed by an attributes list,
separated by whitespaces. Leading and trailing whitespaces are
ignored. Lines that begin with '#' are ignored. Patterns
that begin with a double quote are quoted in C style.
When the pattern matches the path in question, the attributes
listed on the line are given to the path.
Each attribute can be in one of these states for a given path:
Set::
The path has the attribute with special value "true";
this is specified by listing only the name of the
attribute in the attribute list.
Unset::
The path has the attribute with special value "false";
this is specified by listing the name of the attribute
prefixed with a dash `-` in the attribute list.
Set to a value::
The path has the attribute with specified string value;
this is specified by listing the name of the attribute
followed by an equal sign `=` and its value in the
attribute list.
Unspecified::
No pattern matches the path, and nothing says if
the path has or does not have the attribute, the
attribute for the path is said to be Unspecified.
When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute.
The rules by which the pattern matches paths are the same as in
`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions:
- negative patterns are forbidden
- patterns that match a directory do not recursively match paths
inside that directory (so using the trailing-slash `path/` syntax is
pointless in an attributes file; use `path/**` instead)
When deciding what attributes are assigned to a path, Git
consults `$GIT_DIR/info/attributes` file (which has the highest
precedence), `.gitattributes` file in the same directory as the
path in question, and its parent directories up to the toplevel of the
work tree (the further the directory that contains `.gitattributes`
is from the path in question, the lower its precedence). Finally
global and system-wide files are considered (they have the lowest
precedence).
When the `.gitattributes` file is missing from the work tree, the
path in the index is used as a fall-back. During checkout process,
`.gitattributes` in the index is used and then the file in the
working tree is used as a fall-back.
If you wish to affect only a single repository (i.e., to assign
attributes to files that are particular to
one user's workflow for that repository), 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. Attributes that should affect all repositories
for a single user should be placed in a file specified by the
`core.attributesFile` configuration option (see linkgit:git-config[1]).
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.
Attributes for all users on a system should be placed in the
`$(prefix)/etc/gitattributes` file.
Sometimes you would need to override a 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 `!`.
RESERVED BUILTIN_* ATTRIBUTES
-----------------------------
builtin_* is a reserved namespace for builtin attribute values. Any
user defined attributes under this namespace will be ignored and
trigger a warning.
`builtin_objectmode`
~~~~~~~~~~~~~~~~~~~~
This attribute is for filtering files by their file bit modes (40000,
120000, 160000, 100755, 100644). e.g. ':(attr:builtin_objectmode=160000)'.