Avoid scary errors about tagged trees/blobs during git-fetch
[gitweb.git] / Documentation / gitattributes.txt
index d3ac9c718147042a89db90a87d75fee34e778e5a..dd51aa11ea9b271a10b090fb8a5c0acf20885362 100644 (file)
@@ -72,8 +72,8 @@ EFFECTS
 -------
 
 Certain operations by git can be influenced by assigning
-particular attributes to a path.  Currently, three operations
-are attributes-aware.
+particular attributes to a path.  Currently, the following
+operations are attributes-aware.
 
 Checking-out and checking-in
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -145,17 +145,6 @@ sign `$` upon checkout.  Any byte sequence that begins with
 with `$Id$` upon check-in.
 
 
-Interaction between checkin/checkout attributes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In the check-in codepath, the worktree file is first converted
-with `ident` (if specified), and then with `crlf` (again, if
-specified and applicable).
-
-In the check-out codepath, the blob content is first converted
-with `crlf`, and then `ident`.
-
-
 `filter`
 ^^^^^^^^
 
@@ -175,11 +164,10 @@ 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
-"turning something unusable into usable".  In other words, it is
-"hanging yourself because we gave you a long rope" if your
-project uses filtering mechanism in such a way that it makes
-your project unusable unless the checkout is done with a
-specific filter in effect.
+"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
+should still be usable.
 
 
 Interaction between checkin/checkout attributes
@@ -199,7 +187,9 @@ Generating diff text
 ~~~~~~~~~~~~~~~~~~~~
 
 The attribute `diff` affects if `git diff` generates textual
-patch for the path or just says `Binary files differ`.
+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.
 
 Set::
 
@@ -224,7 +214,8 @@ String::
        Diff is shown using the specified custom diff driver.
        The driver program is given its input using the same
        calling convention as used for GIT_EXTERNAL_DIFF
-       program.
+       program.  This name is also used for custom hunk header
+       selection.
 
 
 Defining a custom diff driver
@@ -249,6 +240,50 @@ parameters, just like `GIT_EXTERNAL_DIFF` program is called.
 See gitlink:git[7] for details.
 
 
+Defining a custom hunk-header
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each group of changes (called "hunk") in the textual diff output
+is prefixed with a line of the form:
+
+       @@ -k,l +n,m @@ TEXT
+
+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
+selection however is not suited for some contents, and you can
+use customized pattern to make a selection.
+
+First in .gitattributes, you would assign the `diff` attribute
+for paths.
+
+------------------------
+*.tex  diff=tex
+------------------------
+
+Then, you would define "diff.tex.funcname" configuration to
+specify a regular expression that matches a line that you would
+want to appear as the hunk header, like this:
+
+------------------------
+[diff "tex"]
+       funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"
+------------------------
+
+Note.  A single level of backslashes are eaten by the
+configuration file parser, so you would need to double the
+backslashes; the pattern above picks a line that begins with a
+backslash, and zero or more occurrences of `sub` followed by
+`section` followed by open brace, to the end of line.
+
+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.
+
+
 Performing a three-way merge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -347,7 +382,7 @@ abc -foo -bar
 the attributes given to path `t/abc` are computed as follows:
 
 1. By examining `t/.gitattributes` (which is in the same
-   diretory as the path in question), git finds that the first
+   directory as the path in question), git finds that the first
    line matches.  `merge` attribute is set.  It also finds that
    the second line matches, and attributes `foo` and `bar`
    are unset.
@@ -358,12 +393,12 @@ the attributes given to path `t/abc` are computed as follows:
    and `bar` attributes should be given to this path, so it
    leaves `foo` and `bar` unset.  Attribute `baz` is set.
 
-3. Finally it examines `$GIT_DIR/info/gitattributes`.  This file
+3. Finally it examines `$GIT_DIR/info/attributes`.  This file
    is used to override the in-tree settings.  The first line is
    a match, and `foo` is set, `bar` is reverted to unspecified
    state, and `baz` is unset.
 
-As the result, the attributes assignement to `t/abc` becomes:
+As the result, the attributes assignment to `t/abc` becomes:
 
 ----------------------------------------------------------------
 foo    set to true