1gitattributes(5) 2================ 3 4NAME 5---- 6gitattributes - defining attributes per path 7 8SYNOPSIS 9-------- 10$GIT_DIR/info/attributes, .gitattributes 11 12 13DESCRIPTION 14----------- 15 16A `gitattributes` file is a simple text file that gives 17`attributes` to pathnames. 18 19Each line in `gitattributes` file is of form: 20 21 pattern attr1 attr2 ... 22 23That is, a pattern followed by an attributes list, 24separated by whitespaces. When the pattern matches the 25path in question, the attributes listed on the line are given to 26the path. 27 28Each attribute can be in one of these states for a given path: 29 30Set:: 31 32 The path has the attribute with special value "true"; 33 this is specified by listing only the name of the 34 attribute in the attribute list. 35 36Unset:: 37 38 The path has the attribute with special value "false"; 39 this is specified by listing the name of the attribute 40 prefixed with a dash `-` in the attribute list. 41 42Set to a value:: 43 44 The path has the attribute with specified string value; 45 this is specified by listing the name of the attribute 46 followed by an equal sign `=` and its value in the 47 attribute list. 48 49Unspecified:: 50 51 No pattern matches the path, and nothing says if 52 the path has or does not have the attribute, the 53 attribute for the path is said to be Unspecified. 54 55When more than one pattern matches the path, a later line 56overrides an earlier line. This overriding is done per 57attribute. The rules how the pattern matches paths are the 58same as in `.gitignore` files; see linkgit:gitignore[5]. 59 60When deciding what attributes are assigned to a path, git 61consults `$GIT_DIR/info/attributes` file (which has the highest 62precedence), `.gitattributes` file in the same directory as the 63path in question, and its parent directories up to the toplevel of the 64work tree (the further the directory that contains `.gitattributes` 65is from the path in question, the lower its precedence). Finally 66global and system-wide files are considered (they have the lowest 67precedence). 68 69If you wish to affect only a single repository (i.e., to assign 70attributes to files that are particular to 71one user's workflow for that repository), then 72attributes should be placed in the `$GIT_DIR/info/attributes` file. 73Attributes which should be version-controlled and distributed to other 74repositories (i.e., attributes of interest to all users) should go into 75`.gitattributes` files. Attributes that should affect all repositories 76for a single user should be placed in a file specified by the 77`core.attributesfile` configuration option (see linkgit:git-config[1]). 78Attributes for all users on a system should be placed in the 79`$(prefix)/etc/gitattributes` file. 80 81Sometimes you would need to override an setting of an attribute 82for a path to `unspecified` state. This can be done by listing 83the name of the attribute prefixed with an exclamation point `!`. 84 85 86EFFECTS 87------- 88 89Certain operations by git can be influenced by assigning 90particular attributes to a path. Currently, the following 91operations are attributes-aware. 92 93Checking-out and checking-in 94~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 95 96These attributes affect how the contents stored in the 97repository are copied to the working tree files when commands 98such as 'git checkout' and 'git merge' run. They also affect how 99git stores the contents you prepare in the working tree in the 100repository upon 'git add' and 'git commit'. 101 102`text` 103^^^^^^ 104 105This attribute enables and controls end-of-line normalization. When a 106text file is normalized, its line endings are converted to LF in the 107repository. To control what line ending style is used in the working 108directory, use the `eol` attribute for a single file and the 109`core.eol` configuration variable for all text files. 110 111Set:: 112 113 Setting the `text` attribute on a path enables end-of-line 114 normalization and marks the path as a text file. End-of-line 115 conversion takes place without guessing the content type. 116 117Unset:: 118 119 Unsetting the `text` attribute on a path tells git not to 120 attempt any end-of-line conversion upon checkin or checkout. 121 122Set to string value "auto":: 123 124 When `text` is set to "auto", the path is marked for automatic 125 end-of-line normalization. If git decides that the content is 126 text, its line endings are normalized to LF on checkin. 127 128Unspecified:: 129 130 If the `text` attribute is unspecified, git uses the 131 `core.autocrlf` configuration variable to determine if the 132 file should be converted. 133 134Any other value causes git to act as if `text` has been left 135unspecified. 136 137`eol` 138^^^^^ 139 140This attribute sets a specific line-ending style to be used in the 141working directory. It enables end-of-line normalization without any 142content checks, effectively setting the `text` attribute. 143 144Set to string value "crlf":: 145 146 This setting forces git to normalize line endings for this 147 file on checkin and convert them to CRLF when the file is 148 checked out. 149 150Set to string value "lf":: 151 152 This setting forces git to normalize line endings to LF on 153 checkin and prevents conversion to CRLF when the file is 154 checked out. 155 156Backwards compatibility with `crlf` attribute 157^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 158 159For backwards compatibility, the `crlf` attribute is interpreted as 160follows: 161 162------------------------ 163crlf text 164-crlf -text 165crlf=input eol=lf 166------------------------ 167 168End-of-line conversion 169^^^^^^^^^^^^^^^^^^^^^^ 170 171While git normally leaves file contents alone, it can be configured to 172normalize line endings to LF in the repository and, optionally, to 173convert them to CRLF when files are checked out. 174 175Here is an example that will make git normalize .txt, .vcproj and .sh 176files, ensure that .vcproj files have CRLF and .sh files have LF in 177the working directory, and prevent .jpg files from being normalized 178regardless of their content. 179 180------------------------ 181*.txt text 182*.vcproj eol=crlf 183*.sh eol=lf 184*.jpg -text 185------------------------ 186 187Other source code management systems normalize all text files in their 188repositories, and there are two ways to enable similar automatic 189normalization in git. 190 191If you simply want to have CRLF line endings in your working directory 192regardless of the repository you are working with, you can set the 193config variable "core.autocrlf" without changing any attributes. 194 195------------------------ 196[core] 197 autocrlf = true 198------------------------ 199 200This does not force normalization of all text files, but does ensure 201that text files that you introduce to the repository have their line 202endings normalized to LF when they are added, and that files that are 203already normalized in the repository stay normalized. 204 205If you want to interoperate with a source code management system that 206enforces end-of-line normalization, or you simply want all text files 207in your repository to be normalized, you should instead set the `text` 208attribute to "auto" for _all_ files. 209 210------------------------ 211* text=auto 212------------------------ 213 214This ensures that all files that git considers to be text will have 215normalized (LF) line endings in the repository. The `core.eol` 216configuration variable controls which line endings git will use for 217normalized files in your working directory; the default is to use the 218native line ending for your platform, or CRLF if `core.autocrlf` is 219set. 220 221NOTE: When `text=auto` normalization is enabled in an existing 222repository, any text files containing CRLFs should be normalized. If 223they are not they will be normalized the next time someone tries to 224change them, causing unfortunate misattribution. From a clean working 225directory: 226 227------------------------------------------------- 228$ echo "* text=auto" >>.gitattributes 229$ rm .git/index # Remove the index to force git to 230$ git reset # re-scan the working directory 231$ git status # Show files that will be normalized 232$ git add -u 233$ git add .gitattributes 234$ git commit -m "Introduce end-of-line normalization" 235------------------------------------------------- 236 237If any files that should not be normalized show up in 'git status', 238unset their `text` attribute before running 'git add -u'. 239 240------------------------ 241manual.pdf -text 242------------------------ 243 244Conversely, text files that git does not detect can have normalization 245enabled manually. 246 247------------------------ 248weirdchars.txt text 249------------------------ 250 251If `core.safecrlf` is set to "true" or "warn", git verifies if 252the conversion is reversible for the current setting of 253`core.autocrlf`. For "true", git rejects irreversible 254conversions; for "warn", git only prints a warning but accepts 255an irreversible conversion. The safety triggers to prevent such 256a conversion done to the files in the work tree, but there are a 257few exceptions. Even though... 258 259- 'git add' itself does not touch the files in the work tree, the 260 next checkout would, so the safety triggers; 261 262- 'git apply' to update a text file with a patch does touch the files 263 in the work tree, but the operation is about text files and CRLF 264 conversion is about fixing the line ending inconsistencies, so the 265 safety does not trigger; 266 267- 'git diff' itself does not touch the files in the work tree, it is 268 often run to inspect the changes you intend to next 'git add'. To 269 catch potential problems early, safety triggers. 270 271 272`ident` 273^^^^^^^ 274 275When the attribute `ident` is set for a path, git replaces 276`$Id$` in the blob object with `$Id:`, followed by the 27740-character hexadecimal blob object name, followed by a dollar 278sign `$` upon checkout. Any byte sequence that begins with 279`$Id:` and ends with `$` in the worktree file is replaced 280with `$Id$` upon check-in. 281 282 283`filter` 284^^^^^^^^ 285 286A `filter` attribute can be set to a string value that names a 287filter driver specified in the configuration. 288 289A filter driver consists of a `clean` command and a `smudge` 290command, either of which can be left unspecified. Upon 291checkout, when the `smudge` command is specified, the command is 292fed the blob object from its standard input, and its standard 293output is used to update the worktree file. Similarly, the 294`clean` command is used to convert the contents of worktree file 295upon checkin. 296 297A missing filter driver definition in the config is not an error 298but makes the filter a no-op passthru. 299 300The content filtering is done to massage the content into a 301shape that is more convenient for the platform, filesystem, and 302the user to use. The key phrase here is "more convenient" and not 303"turning something unusable into usable". In other words, the 304intent is that if someone unsets the filter driver definition, 305or does not have the appropriate filter program, the project 306should still be usable. 307 308For example, in .gitattributes, you would assign the `filter` 309attribute for paths. 310 311------------------------ 312*.c filter=indent 313------------------------ 314 315Then you would define a "filter.indent.clean" and "filter.indent.smudge" 316configuration in your .git/config to specify a pair of commands to 317modify the contents of C programs when the source files are checked 318in ("clean" is run) and checked out (no change is made because the 319command is "cat"). 320 321------------------------ 322[filter "indent"] 323 clean = indent 324 smudge = cat 325------------------------ 326 327 328Interaction between checkin/checkout attributes 329^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 330 331In the check-in codepath, the worktree file is first converted 332with `filter` driver (if specified and corresponding driver 333defined), then the result is processed with `ident` (if 334specified), and then finally with `text` (again, if specified 335and applicable). 336 337In the check-out codepath, the blob content is first converted 338with `text`, and then `ident` and fed to `filter`. 339 340 341Generating diff text 342~~~~~~~~~~~~~~~~~~~~ 343 344`diff` 345^^^^^^ 346 347The attribute `diff` affects how 'git' generates diffs for particular 348files. It can tell git whether to generate a textual patch for the path 349or to treat the path as a binary file. It can also affect what line is 350shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an 351external command to generate the diff, or ask git to convert binary 352files to a text format before generating the diff. 353 354Set:: 355 356 A path to which the `diff` attribute is set is treated 357 as text, even when they contain byte values that 358 normally never appear in text files, such as NUL. 359 360Unset:: 361 362 A path to which the `diff` attribute is unset will 363 generate `Binary files differ` (or a binary patch, if 364 binary patches are enabled). 365 366Unspecified:: 367 368 A path to which the `diff` attribute is unspecified 369 first gets its contents inspected, and if it looks like 370 text, it is treated as text. Otherwise it would 371 generate `Binary files differ`. 372 373String:: 374 375 Diff is shown using the specified diff driver. Each driver may 376 specify one or more options, as described in the following 377 section. The options for the diff driver "foo" are defined 378 by the configuration variables in the "diff.foo" section of the 379 git config file. 380 381 382Defining an external diff driver 383^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 384 385The definition of a diff driver is done in `gitconfig`, not 386`gitattributes` file, so strictly speaking this manual page is a 387wrong place to talk about it. However... 388 389To define an external diff driver `jcdiff`, add a section to your 390`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: 391 392---------------------------------------------------------------- 393[diff "jcdiff"] 394 command = j-c-diff 395---------------------------------------------------------------- 396 397When git needs to show you a diff for the path with `diff` 398attribute set to `jcdiff`, it calls the command you specified 399with the above configuration, i.e. `j-c-diff`, with 7 400parameters, just like `GIT_EXTERNAL_DIFF` program is called. 401See linkgit:git[1] for details. 402 403 404Defining a custom hunk-header 405^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 406 407Each group of changes (called a "hunk") in the textual diff output 408is prefixed with a line of the form: 409 410 @@ -k,l +n,m @@ TEXT 411 412This is called a 'hunk header'. The "TEXT" portion is by default a line 413that begins with an alphabet, an underscore or a dollar sign; this 414matches what GNU 'diff -p' output uses. This default selection however 415is not suited for some contents, and you can use a customized pattern 416to make a selection. 417 418First, in .gitattributes, you would assign the `diff` attribute 419for paths. 420 421------------------------ 422*.tex diff=tex 423------------------------ 424 425Then, you would define a "diff.tex.xfuncname" configuration to 426specify a regular expression that matches a line that you would 427want to appear as the hunk header "TEXT". Add a section to your 428`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: 429 430------------------------ 431[diff "tex"] 432 xfuncname = "^(\\\\(sub)*section\\{.*)$" 433------------------------ 434 435Note. A single level of backslashes are eaten by the 436configuration file parser, so you would need to double the 437backslashes; the pattern above picks a line that begins with a 438backslash, and zero or more occurrences of `sub` followed by 439`section` followed by open brace, to the end of line. 440 441There are a few built-in patterns to make this easier, and `tex` 442is one of them, so you do not have to write the above in your 443configuration file (you still need to enable this with the 444attribute mechanism, via `.gitattributes`). The following built in 445patterns are available: 446 447- `bibtex` suitable for files with BibTeX coded references. 448 449- `cpp` suitable for source code in the C and C++ languages. 450 451- `html` suitable for HTML/XHTML documents. 452 453- `java` suitable for source code in the Java language. 454 455- `objc` suitable for source code in the Objective-C language. 456 457- `pascal` suitable for source code in the Pascal/Delphi language. 458 459- `php` suitable for source code in the PHP language. 460 461- `python` suitable for source code in the Python language. 462 463- `ruby` suitable for source code in the Ruby language. 464 465- `tex` suitable for source code for LaTeX documents. 466 467 468Customizing word diff 469^^^^^^^^^^^^^^^^^^^^^ 470 471You can customize the rules that `git diff --word-diff` uses to 472split words in a line, by specifying an appropriate regular expression 473in the "diff.*.wordRegex" configuration variable. For example, in TeX 474a backslash followed by a sequence of letters forms a command, but 475several such commands can be run together without intervening 476whitespace. To separate them, use a regular expression in your 477`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: 478 479------------------------ 480[diff "tex"] 481 wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+" 482------------------------ 483 484A built-in pattern is provided for all languages listed in the 485previous section. 486 487 488Performing text diffs of binary files 489^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 490 491Sometimes it is desirable to see the diff of a text-converted 492version of some binary files. For example, a word processor 493document can be converted to an ASCII text representation, and 494the diff of the text shown. Even though this conversion loses 495some information, the resulting diff is useful for human 496viewing (but cannot be applied directly). 497 498The `textconv` config option is used to define a program for 499performing such a conversion. The program should take a single 500argument, the name of a file to convert, and produce the 501resulting text on stdout. 502 503For example, to show the diff of the exif information of a 504file instead of the binary information (assuming you have the 505exif tool installed), add the following section to your 506`$GIT_DIR/config` file (or `$HOME/.gitconfig` file): 507 508------------------------ 509[diff "jpg"] 510 textconv = exif 511------------------------ 512 513NOTE: The text conversion is generally a one-way conversion; 514in this example, we lose the actual image contents and focus 515just on the text data. This means that diffs generated by 516textconv are _not_ suitable for applying. For this reason, 517only `git diff` and the `git log` family of commands (i.e., 518log, whatchanged, show) will perform text conversion. `git 519format-patch` will never generate this output. If you want to 520send somebody a text-converted diff of a binary file (e.g., 521because it quickly conveys the changes you have made), you 522should generate it separately and send it as a comment _in 523addition to_ the usual binary diff that you might send. 524 525Because text conversion can be slow, especially when doing a 526large number of them with `git log -p`, git provides a mechanism 527to cache the output and use it in future diffs. To enable 528caching, set the "cachetextconv" variable in your diff driver's 529config. For example: 530 531------------------------ 532[diff "jpg"] 533 textconv = exif 534 cachetextconv = true 535------------------------ 536 537This will cache the result of running "exif" on each blob 538indefinitely. If you change the textconv config variable for a 539diff driver, git will automatically invalidate the cache entries 540and re-run the textconv filter. If you want to invalidate the 541cache manually (e.g., because your version of "exif" was updated 542and now produces better output), you can remove the cache 543manually with `git update-ref -d refs/notes/textconv/jpg` (where 544"jpg" is the name of the diff driver, as in the example above). 545 546Performing a three-way merge 547~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 548 549`merge` 550^^^^^^^ 551 552The attribute `merge` affects how three versions of a file is 553merged when a file-level merge is necessary during `git merge`, 554and other commands such as `git revert` and `git cherry-pick`. 555 556Set:: 557 558 Built-in 3-way merge driver is used to merge the 559 contents in a way similar to 'merge' command of `RCS` 560 suite. This is suitable for ordinary text files. 561 562Unset:: 563 564 Take the version from the current branch as the 565 tentative merge result, and declare that the merge has 566 conflicts. This is suitable for binary files that does 567 not have a well-defined merge semantics. 568 569Unspecified:: 570 571 By default, this uses the same built-in 3-way merge 572 driver as is the case the `merge` attribute is set. 573 However, `merge.default` configuration variable can name 574 different merge driver to be used for paths to which the 575 `merge` attribute is unspecified. 576 577String:: 578 579 3-way merge is performed using the specified custom 580 merge driver. The built-in 3-way merge driver can be 581 explicitly specified by asking for "text" driver; the 582 built-in "take the current branch" driver can be 583 requested with "binary". 584 585 586Built-in merge drivers 587^^^^^^^^^^^^^^^^^^^^^^ 588 589There are a few built-in low-level merge drivers defined that 590can be asked for via the `merge` attribute. 591 592text:: 593 594 Usual 3-way file level merge for text files. Conflicted 595 regions are marked with conflict markers `<<<<<<<`, 596 `=======` and `>>>>>>>`. The version from your branch 597 appears before the `=======` marker, and the version 598 from the merged branch appears after the `=======` 599 marker. 600 601binary:: 602 603 Keep the version from your branch in the work tree, but 604 leave the path in the conflicted state for the user to 605 sort out. 606 607union:: 608 609 Run 3-way file level merge for text files, but take 610 lines from both versions, instead of leaving conflict 611 markers. This tends to leave the added lines in the 612 resulting file in random order and the user should 613 verify the result. Do not use this if you do not 614 understand the implications. 615 616 617Defining a custom merge driver 618^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 619 620The definition of a merge driver is done in the `.git/config` 621file, not in the `gitattributes` file, so strictly speaking this 622manual page is a wrong place to talk about it. However... 623 624To define a custom merge driver `filfre`, add a section to your 625`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: 626 627---------------------------------------------------------------- 628[merge "filfre"] 629 name = feel-free merge driver 630 driver = filfre %O %A %B 631 recursive = binary 632---------------------------------------------------------------- 633 634The `merge.*.name` variable gives the driver a human-readable 635name. 636 637The `merge.*.driver` variable's value is used to construct a 638command to run to merge ancestor's version (`%O`), current 639version (`%A`) and the other branches' version (`%B`). These 640three tokens are replaced with the names of temporary files that 641hold the contents of these versions when the command line is 642built. Additionally, %L will be replaced with the conflict marker 643size (see below). 644 645The merge driver is expected to leave the result of the merge in 646the file named with `%A` by overwriting it, and exit with zero 647status if it managed to merge them cleanly, or non-zero if there 648were conflicts. 649 650The `merge.*.recursive` variable specifies what other merge 651driver to use when the merge driver is called for an internal 652merge between common ancestors, when there are more than one. 653When left unspecified, the driver itself is used for both 654internal merge and the final merge. 655 656 657`conflict-marker-size` 658^^^^^^^^^^^^^^^^^^^^^^ 659 660This attribute controls the length of conflict markers left in 661the work tree file during a conflicted merge. Only setting to 662the value to a positive integer has any meaningful effect. 663 664For example, this line in `.gitattributes` can be used to tell the merge 665machinery to leave much longer (instead of the usual 7-character-long) 666conflict markers when merging the file `Documentation/git-merge.txt` 667results in a conflict. 668 669------------------------ 670Documentation/git-merge.txt conflict-marker-size=32 671------------------------ 672 673 674Checking whitespace errors 675~~~~~~~~~~~~~~~~~~~~~~~~~~ 676 677`whitespace` 678^^^^^^^^^^^^ 679 680The `core.whitespace` configuration variable allows you to define what 681'diff' and 'apply' should consider whitespace errors for all paths in 682the project (See linkgit:git-config[1]). This attribute gives you finer 683control per path. 684 685Set:: 686 687 Notice all types of potential whitespace errors known to git. 688 689Unset:: 690 691 Do not notice anything as error. 692 693Unspecified:: 694 695 Use the value of `core.whitespace` configuration variable to 696 decide what to notice as error. 697 698String:: 699 700 Specify a comma separate list of common whitespace problems to 701 notice in the same format as `core.whitespace` configuration 702 variable. 703 704 705Creating an archive 706~~~~~~~~~~~~~~~~~~~ 707 708`export-ignore` 709^^^^^^^^^^^^^^^ 710 711Files and directories with the attribute `export-ignore` won't be added to 712archive files. 713 714`export-subst` 715^^^^^^^^^^^^^^ 716 717If the attribute `export-subst` is set for a file then git will expand 718several placeholders when adding this file to an archive. The 719expansion depends on the availability of a commit ID, i.e., if 720linkgit:git-archive[1] has been given a tree instead of a commit or a 721tag then no replacement will be done. The placeholders are the same 722as those for the option `--pretty=format:` of linkgit:git-log[1], 723except that they need to be wrapped like this: `$Format:PLACEHOLDERS$` 724in the file. E.g. the string `$Format:%H$` will be replaced by the 725commit hash. 726 727 728Packing objects 729~~~~~~~~~~~~~~~ 730 731`delta` 732^^^^^^^ 733 734Delta compression will not be attempted for blobs for paths with the 735attribute `delta` set to false. 736 737 738Viewing files in GUI tools 739~~~~~~~~~~~~~~~~~~~~~~~~~~ 740 741`encoding` 742^^^^^^^^^^ 743 744The value of this attribute specifies the character encoding that should 745be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to 746display the contents of the relevant file. Note that due to performance 747considerations linkgit:gitk[1] does not use this attribute unless you 748manually enable per-file encodings in its options. 749 750If this attribute is not set or has an invalid value, the value of the 751`gui.encoding` configuration variable is used instead 752(See linkgit:git-config[1]). 753 754 755USING ATTRIBUTE MACROS 756---------------------- 757 758You do not want any end-of-line conversions applied to, nor textual diffs 759produced for, any binary file you track. You would need to specify e.g. 760 761------------ 762*.jpg -text -diff 763------------ 764 765but that may become cumbersome, when you have many attributes. Using 766attribute macros, you can specify groups of attributes set or unset at 767the same time. The system knows a built-in attribute macro, `binary`: 768 769------------ 770*.jpg binary 771------------ 772 773which is equivalent to the above. Note that the attribute macros can only 774be "Set" (see the above example that sets "binary" macro as if it were an 775ordinary attribute --- setting it in turn unsets "text" and "diff"). 776 777 778DEFINING ATTRIBUTE MACROS 779------------------------- 780 781Custom attribute macros can be defined only in the `.gitattributes` file 782at the toplevel (i.e. not in any subdirectory). The built-in attribute 783macro "binary" is equivalent to: 784 785------------ 786[attr]binary -diff -text 787------------ 788 789 790EXAMPLE 791------- 792 793If you have these three `gitattributes` file: 794 795---------------------------------------------------------------- 796(in $GIT_DIR/info/attributes) 797 798a* foo !bar -baz 799 800(in .gitattributes) 801abc foo bar baz 802 803(in t/.gitattributes) 804ab* merge=filfre 805abc -foo -bar 806*.c frotz 807---------------------------------------------------------------- 808 809the attributes given to path `t/abc` are computed as follows: 810 8111. By examining `t/.gitattributes` (which is in the same 812 directory as the path in question), git finds that the first 813 line matches. `merge` attribute is set. It also finds that 814 the second line matches, and attributes `foo` and `bar` 815 are unset. 816 8172. Then it examines `.gitattributes` (which is in the parent 818 directory), and finds that the first line matches, but 819 `t/.gitattributes` file already decided how `merge`, `foo` 820 and `bar` attributes should be given to this path, so it 821 leaves `foo` and `bar` unset. Attribute `baz` is set. 822 8233. Finally it examines `$GIT_DIR/info/attributes`. This file 824 is used to override the in-tree settings. The first line is 825 a match, and `foo` is set, `bar` is reverted to unspecified 826 state, and `baz` is unset. 827 828As the result, the attributes assignment to `t/abc` becomes: 829 830---------------------------------------------------------------- 831foo set to true 832bar unspecified 833baz set to false 834merge set to string value "filfre" 835frotz unspecified 836---------------------------------------------------------------- 837 838 839 840GIT 841--- 842Part of the linkgit:git[1] suite