Code

Update draft release notes for 1.6.0.1
[git.git] / Documentation / gitattributes.txt
index 20cf8ff81673265629028b49c34e0393063fd6b1..db16b0ca5b8146361a379de894a1394e0950fd38 100644 (file)
@@ -63,6 +63,13 @@ path in question, and its parent directories (the further the
 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 `!`.
@@ -80,9 +87,9 @@ Checking-out and checking-in
 
 These attributes affect how the contents stored in the
 repository are copied to the working tree files when commands
-such as `git checkout` and `git merge` run.  They also affect how
+such as 'git-checkout' and 'git-merge' run.  They also affect how
 git stores the contents you prepare in the working tree in the
-repository upon `git add` and `git commit`.
+repository upon 'git-add' and 'git-commit'.
 
 `crlf`
 ^^^^^^
@@ -133,6 +140,26 @@ When `core.autocrlf` is set to "input", line endings are
 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`
 ^^^^^^^
@@ -148,22 +175,23 @@ with `$Id$` upon check-in.
 `filter`
 ^^^^^^^^
 
-A `filter` attribute can be set to a string value.  This names
+A `filter` attribute can be set to a string value that names a
 filter driver specified in the configuration.
 
-A filter driver consists of `clean` command and `smudge`
+A filter driver consists of a `clean` command and a `smudge`
 command, either of which can be left unspecified.  Upon
-checkout, when `smudge` command is specified, the command is fed
-the blob object from its standard input, and its standard output
-is used to update the worktree file.  Similarly, `clean` command
-is used to convert the contents of worktree file upon checkin.
+checkout, when the `smudge` command is specified, the command is
+fed the blob object from its standard input, and its standard
+output is used to update the worktree file.  Similarly, the
+`clean` command is used to convert the contents of worktree file
+upon checkin.
 
-Missing filter driver definition in the config is not an error
+A missing filter driver definition in the config is not an error
 but makes the filter a no-op passthru.
 
 The content filtering is done to massage the content into a
 shape that is more convenient for the platform, filesystem, and
-the user to use.  The keyword here is "more convenient" and not
+the user to use.  The key phrase here is "more convenient" and not
 "turning something unusable into usable".  In other words, the
 intent is that if someone unsets the filter driver definition,
 or does not have the appropriate filter program, the project
@@ -186,7 +214,7 @@ with `crlf`, and then `ident` and fed to `filter`.
 Generating diff text
 ~~~~~~~~~~~~~~~~~~~~
 
-The attribute `diff` affects if `git diff` generates textual
+The attribute `diff` affects if 'git-diff' generates textual
 patch for the path or just says `Binary files differ`.  It also
 can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
 line.
@@ -237,7 +265,7 @@ When git needs to show you a diff for the path with `diff`
 attribute set to `jcdiff`, it calls the command you specified
 with the above configuration, i.e. `j-c-diff`, with 7
 parameters, just like `GIT_EXTERNAL_DIFF` program is called.
-See gitlink:git[7] for details.
+See linkgit:git[1] for details.
 
 
 Defining a custom hunk-header
@@ -250,7 +278,7 @@ is prefixed with a line of the form:
 
 The text is called 'hunk header', and by default a line that
 begins with an alphabet, an underscore or a dollar sign is used,
-which matches what GNU `diff -p` output uses.  This default
+which matches what GNU 'diff -p' output uses.  This default
 selection however is not suited for some contents, and you can
 use customized pattern to make a selection.
 
@@ -279,9 +307,18 @@ backslash, and zero or more occurrences of `sub` followed by
 There are a few built-in patterns to make this easier, and `tex`
 is one of them, so you do not have to write the above in your
 configuration file (you still need to enable this with the
-attribute mechanism, via `.gitattributes`).  Another built-in
-pattern is defined for `java` that defines a pattern suitable
-for program text in Java language.
+attribute mechanism, via `.gitattributes`).  The following built in
+patterns are available:
+
+- `bibtex` suitable for files with BibTeX coded references.
+
+- `java` suitable for source code in the Java lanugage.
+
+- `pascal` suitable for source code in the Pascal/Delphi language.
+
+- `ruby` suitable for source code in the Ruby language.
+
+- `tex` suitable for source code for LaTeX documents.
 
 
 Performing a three-way merge
@@ -294,7 +331,7 @@ and other programs such as `git revert` and `git cherry-pick`.
 Set::
 
        Built-in 3-way merge driver is used to merge the
-       contents in a way similar to `merge` command of `RCS`
+       contents in a way similar to 'merge' command of `RCS`
        suite.  This is suitable for ordinary text files.
 
 Unset::
@@ -321,12 +358,43 @@ String::
        requested with "binary".
 
 
+Built-in merge drivers
+^^^^^^^^^^^^^^^^^^^^^^
+
+There are a few built-in low-level merge drivers defined that
+can be asked for via the `merge` attribute.
+
+text::
+
+       Usual 3-way file level merge for text files.  Conflicted
+       regions are marked with conflict markers `<<<<<<<`,
+       `=======` and `>>>>>>>`.  The version from your branch
+       appears before the `=======` marker, and the version
+       from the merged branch appears after the `=======`
+       marker.
+
+binary::
+
+       Keep the version from your branch in the work tree, but
+       leave the path in the conflicted state for the user to
+       sort out.
+
+union::
+
+       Run 3-way file level merge for text files, but take
+       lines from both versions, instead of leaving conflict
+       markers.  This tends to leave the added lines in the
+       resulting file in random order and the user should
+       verify the result. Do not use this if you do not
+       understand the implications.
+
+
 Defining a custom merge driver
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The definition of a merge driver is done in `gitconfig` not
-`gitattributes` file, so strictly speaking this manual page is a
-wrong place to talk about it.  However...
+The definition of a merge driver is done in the `.git/config`
+file, not in the `gitattributes` file, so strictly speaking this
+manual page is a wrong place to talk about it.  However...
 
 To define a custom merge driver `filfre`, add a section to your
 `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
@@ -360,6 +428,60 @@ When left unspecified, the driver itself is used for both
 internal merge and the final merge.
 
 
+Checking whitespace errors
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`whitespace`
+^^^^^^^^^^^^
+
+The `core.whitespace` configuration variable allows you to define what
+'diff' and 'apply' should consider whitespace errors for all paths in
+the project (See linkgit:git-config[1]).  This attribute gives you finer
+control per path.
+
+Set::
+
+       Notice all types of potential whitespace errors known to git.
+
+Unset::
+
+       Do not notice anything as error.
+
+Unspecified::
+
+       Use the value of `core.whitespace` configuration variable to
+       decide what to notice as error.
+
+String::
+
+       Specify a comma separate list of common whitespace problems to
+       notice in the same format as `core.whitespace` configuration
+       variable.
+
+
+Creating an archive
+~~~~~~~~~~~~~~~~~~~
+
+`export-ignore`
+^^^^^^^^^^^^^^^
+
+Files and directories with the attribute `export-ignore` won't be added to
+archive files.
+
+`export-subst`
+^^^^^^^^^^^^^^
+
+If the attribute `export-subst` is set for a file then git will expand
+several placeholders when adding this file to an archive.  The
+expansion depends on the availability of a commit ID, i.e., if
+linkgit:git-archive[1] has been given a tree instead of a commit or a
+tag then no replacement will be done.  The placeholders are the same
+as those for the option `--pretty=format:` of linkgit:git-log[1],
+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
+in the file.  E.g. the string `$Format:%H$` will be replaced by the
+commit hash.
+
+
 EXAMPLE
 -------
 
@@ -409,23 +531,7 @@ frotz      unspecified
 ----------------------------------------------------------------
 
 
-Creating an archive
-~~~~~~~~~~~~~~~~~~~
-
-`export-subst`
-^^^^^^^^^^^^^^
-
-If the attribute `export-subst` is set for a file then git will expand
-several placeholders when adding this file to an archive.  The
-expansion depends on the availability of a commit ID, i.e. if
-gitlink:git-archive[1] has been given a tree instead of a commit or a
-tag then no replacement will be done.  The placeholders are the same
-as those for the option `--pretty=format:` of gitlink:git-log[1],
-except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
-in the file.  E.g. the string `$Format:%H$` will be replaced by the
-commit hash.
-
 
 GIT
 ---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[1] suite