| blob | 2ef690bdf37d1c27b5510f5e7ea7603fed5413f5 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 gitattributes(5) Manual Page
574 </h1>
577 <p>gitattributes -
578 defining attributes per path
579 </p>
580 </div>
581 </div>
586 </div>
595 </div></div>
597 separated by whitespaces. When the pattern matches the
598 path in question, the attributes listed on the line are given to
599 the path.</p></div>
600 <div class="paragraph"><p>Each attribute can be in one of these states for a given path:</p></div>
603 Set
604 </dt>
605 <dd>
606 <p>
607 The path has the attribute with special value "true";
608 this is specified by listing only the name of the
609 attribute in the attribute list.
610 </p>
611 </dd>
613 Unset
614 </dt>
615 <dd>
616 <p>
617 The path has the attribute with special value "false";
618 this is specified by listing the name of the attribute
620 </p>
621 </dd>
623 Set to a value
624 </dt>
625 <dd>
626 <p>
627 The path has the attribute with specified string value;
628 this is specified by listing the name of the attribute
630 attribute list.
631 </p>
632 </dd>
634 Unspecified
635 </dt>
636 <dd>
637 <p>
638 No pattern matches the path, and nothing says if
639 the path has or does not have the attribute, the
640 attribute for the path is said to be Unspecified.
641 </p>
642 </dd>
643 </dl></div>
645 overrides an earlier line. This overriding is done per
646 attribute. The rules how the pattern matches paths are the
651 path in question, and its parent directories up to the toplevel of the
653 is from the path in question, the lower its precedence). Finally
654 global and system-wide files are considered (they have the lowest
655 precedence).</p></div>
657 attributes to files that are particular to
658 one user’s workflow for that repository), then
660 Attributes which should be version-controlled and distributed to other
661 repositories (i.e., attributes of interest to all users) should go into
663 for a single user should be placed in a file specified by the
664 <tt>core.attributesfile</tt> configuration option (see <a href="git-config.html">git-config(1)</a>).
665 Attributes for all users on a system should be placed in the
670 </div>
674 particular attributes to a path. Currently, the following
675 operations are attributes-aware.</p></div>
676 <h3 id="_checking_out_and_checking_in">Checking-out and checking-in</h3><div style="clear:left"></div>
678 repository are copied to the working tree files when commands
680 git stores the contents you prepare in the working tree in the
684 text file is normalized, its line endings are converted to LF in the
685 repository. To control what line ending style is used in the working
690 Set
691 </dt>
692 <dd>
693 <p>
695 normalization and marks the path as a text file. End-of-line
696 conversion takes place without guessing the content type.
697 </p>
698 </dd>
700 Unset
701 </dt>
702 <dd>
703 <p>
705 attempt any end-of-line conversion upon checkin or checkout.
706 </p>
707 </dd>
709 Set to string value "auto"
710 </dt>
711 <dd>
712 <p>
714 end-of-line normalization. If git decides that the content is
715 text, its line endings are normalized to LF on checkin.
716 </p>
717 </dd>
719 Unspecified
720 </dt>
721 <dd>
722 <p>
725 file should be converted.
726 </p>
727 </dd>
728 </dl></div>
730 unspecified.</p></div>
733 working directory. It enables end-of-line normalization without any
737 Set to string value "crlf"
738 </dt>
739 <dd>
740 <p>
741 This setting forces git to normalize line endings for this
742 file on checkin and convert them to CRLF when the file is
743 checked out.
744 </p>
745 </dd>
747 Set to string value "lf"
748 </dt>
749 <dd>
750 <p>
751 This setting forces git to normalize line endings to LF on
752 checkin and prevents conversion to CRLF when the file is
753 checked out.
754 </p>
755 </dd>
756 </dl></div>
757 <h4 id="_backwards_compatibility_with_tt_crlf_tt_attribute">Backwards compatibility with <tt>crlf</tt> attribute</h4>
758 <div class="paragraph"><p>For backwards compatibility, the <tt>crlf</tt> attribute is interpreted as
759 follows:</p></div>
762 <pre><tt>crlf text
763 -crlf -text
764 crlf=input eol=lf</tt></pre>
765 </div></div>
767 <div class="paragraph"><p>While git normally leaves file contents alone, it can be configured to
768 normalize line endings to LF in the repository and, optionally, to
769 convert them to CRLF when files are checked out.</p></div>
771 files, ensure that .vcproj files have CRLF and .sh files have LF in
772 the working directory, and prevent .jpg files from being normalized
773 regardless of their content.</p></div>
776 <pre><tt>*.txt text
777 *.vcproj eol=crlf
778 *.sh eol=lf
779 *.jpg -text</tt></pre>
780 </div></div>
781 <div class="paragraph"><p>Other source code management systems normalize all text files in their
782 repositories, and there are two ways to enable similar automatic
783 normalization in git.</p></div>
784 <div class="paragraph"><p>If you simply want to have CRLF line endings in your working directory
785 regardless of the repository you are working with, you can set the
789 <pre><tt>[core]
790 autocrlf = true</tt></pre>
791 </div></div>
793 that text files that you introduce to the repository have their line
794 endings normalized to LF when they are added, and that files that are
795 already normalized in the repository stay normalized.</p></div>
797 enforces end-of-line normalization, or you simply want all text files
803 </div></div>
806 configuration variable controls which line endings git will use for
807 normalized files in your working directory; the default is to use the
809 set.</p></div>
811 <table><tr>
814 </td>
816 repository, any text files containing CRLFs should be normalized. If
817 they are not they will be normalized the next time someone tries to
818 change them, causing unfortunate misattribution. From a clean working
819 directory:</td>
820 </tr></table>
821 </div>
825 $ rm .git/index # Remove the index to force git to
826 $ git reset # re-scan the working directory
827 $ git status # Show files that will be normalized
828 $ git add -u
829 $ git add .gitattributes
831 </div></div>
832 <div class="paragraph"><p>If any files that should not be normalized show up in <em>git status</em>,
837 </div></div>
838 <div class="paragraph"><p>Conversely, text files that git does not detect can have normalization
839 enabled manually.</p></div>
843 </div></div>
845 the conversion is reversible for the current setting of
847 conversions; for "warn", git only prints a warning but accepts
848 an irreversible conversion. The safety triggers to prevent such
849 a conversion done to the files in the work tree, but there are a
852 <li>
853 <p>
855 next checkout would, so the safety triggers;
856 </p>
857 </li>
858 <li>
859 <p>
861 in the work tree, but the operation is about text files and CRLF
862 conversion is about fixing the line ending inconsistencies, so the
863 safety does not trigger;
864 </p>
865 </li>
866 <li>
867 <p>
870 catch potential problems early, safety triggers.
871 </p>
872 </li>
873 </ul></div>
877 40-character hexadecimal blob object name, followed by a dollar
883 filter driver specified in the configuration.</p></div>
884 <div class="paragraph"><p>A filter driver consists of a <tt>clean</tt> command and a <tt>smudge</tt>
885 command, either of which can be left unspecified. Upon
887 fed the blob object from its standard input, and its standard
888 output is used to update the worktree file. Similarly, the
890 upon checkin.</p></div>
892 but makes the filter a no-op passthru.</p></div>
894 shape that is more convenient for the platform, filesystem, and
895 the user to use. The key phrase here is "more convenient" and not
896 "turning something unusable into usable". In other words, the
897 intent is that if someone unsets the filter driver definition,
898 or does not have the appropriate filter program, the project
899 should still be usable.</p></div>
901 attribute for paths.</p></div>
905 </div></div>
906 <div class="paragraph"><p>Then you would define a "filter.indent.clean" and "filter.indent.smudge"
907 configuration in your .git/config to specify a pair of commands to
908 modify the contents of C programs when the source files are checked
909 in ("clean" is run) and checked out (no change is made because the
914 clean = indent
915 smudge = cat</tt></pre>
916 </div></div>
917 <div class="paragraph"><p>For best results, <tt>clean</tt> should not alter its output further if it is
921 section on merging below.</p></div>
922 <div class="paragraph"><p>The "indent" filter is well-behaved in this regard: it will not modify
923 input that is already correctly indented. In this case, the lack of a
925 without modifying it.</p></div>
927 the file the filter is working on. A filter might use this in keyword
928 substitution. For example:</p></div>
932 clean = git-p4-filter --clean %f
933 smudge = git-p4-filter --smudge %f</tt></pre>
934 </div></div>
935 <h4 id="_interaction_between_checkin_checkout_attributes">Interaction between checkin/checkout attributes</h4>
940 and applicable).</p></div>
943 <h4 id="_merging_branches_with_differing_checkin_checkout_attributes">Merging branches with differing checkin/checkout attributes</h4>
945 repository format for that file to change, such as adding a
946 clean/smudge filter or text/eol/ident attributes, merging anything
947 where the attribute is not in place would normally cause merge
948 conflicts.</p></div>
949 <div class="paragraph"><p>To prevent these unnecessary merge conflicts, git can be told to run a
950 virtual check-out and check-in of all three stages of a file when
952 configuration variable. This prevents changes caused by check-in
953 conversion from causing spurious merge conflicts when a converted file
954 is merged with an unconverted file.</p></div>
955 <div class="paragraph"><p>As long as a "smudge→clean" results in the same output as a "clean"
956 even on files that are already smudged, this strategy will
957 automatically resolve all filter-related conflicts. Filters that do
958 not act in this way may cause additional merge conflicts that must be
959 resolved manually.</p></div>
962 <div class="paragraph"><p>The attribute <tt>diff</tt> affects how <em>git</em> generates diffs for particular
963 files. It can tell git whether to generate a textual patch for the path
964 or to treat the path as a binary file. It can also affect what line is
966 external command to generate the diff, or ask git to convert binary
967 files to a text format before generating the diff.</p></div>
970 Set
971 </dt>
972 <dd>
973 <p>
975 as text, even when they contain byte values that
976 normally never appear in text files, such as NUL.
977 </p>
978 </dd>
980 Unset
981 </dt>
982 <dd>
983 <p>
986 binary patches are enabled).
987 </p>
988 </dd>
990 Unspecified
991 </dt>
992 <dd>
993 <p>
995 first gets its contents inspected, and if it looks like
996 text, it is treated as text. Otherwise it would
998 </p>
999 </dd>
1001 String
1002 </dt>
1003 <dd>
1004 <p>
1005 Diff is shown using the specified diff driver. Each driver may
1006 specify one or more options, as described in the following
1007 section. The options for the diff driver "foo" are defined
1008 by the configuration variables in the "diff.foo" section of the
1009 git config file.
1010 </p>
1011 </dd>
1012 </dl></div>
1017 <div class="paragraph"><p>To define an external diff driver <tt>jcdiff</tt>, add a section to your
1022 command = j-c-diff</tt></pre>
1023 </div></div>
1031 is prefixed with a line of the form:</p></div>
1035 </div></div>
1036 <div class="paragraph"><p>This is called a <em>hunk header</em>. The "TEXT" portion is by default a line
1037 that begins with an alphabet, an underscore or a dollar sign; this
1039 is not suited for some contents, and you can use a customized pattern
1040 to make a selection.</p></div>
1041 <div class="paragraph"><p>First, in .gitattributes, you would assign the <tt>diff</tt> attribute
1042 for paths.</p></div>
1046 </div></div>
1048 specify a regular expression that matches a line that you would
1049 want to appear as the hunk header "TEXT". Add a section to your
1055 </div></div>
1057 configuration file parser, so you would need to double the
1058 backslashes; the pattern above picks a line that begins with a
1061 <div class="paragraph"><p>There are a few built-in patterns to make this easier, and <tt>tex</tt>
1062 is one of them, so you do not have to write the above in your
1063 configuration file (you still need to enable this with the
1065 patterns are available:</p></div>
1067 <li>
1068 <p>
1070 </p>
1071 </li>
1072 <li>
1073 <p>
1075 </p>
1076 </li>
1077 <li>
1078 <p>
1080 </p>
1081 </li>
1082 <li>
1083 <p>
1085 </p>
1086 </li>
1087 <li>
1088 <p>
1090 </p>
1091 </li>
1092 <li>
1093 <p>
1095 </p>
1096 </li>
1097 <li>
1098 <p>
1100 </p>
1101 </li>
1102 <li>
1103 <p>
1105 </p>
1106 </li>
1107 <li>
1108 <p>
1110 </p>
1111 </li>
1112 <li>
1113 <p>
1115 </p>
1116 </li>
1117 <li>
1118 <p>
1120 </p>
1121 </li>
1122 <li>
1123 <p>
1125 </p>
1126 </li>
1127 <li>
1128 <p>
1130 </p>
1131 </li>
1132 </ul></div>
1134 <div class="paragraph"><p>You can customize the rules that <tt>git diff --word-diff</tt> uses to
1135 split words in a line, by specifying an appropriate regular expression
1136 in the "diff.*.wordRegex" configuration variable. For example, in TeX
1137 a backslash followed by a sequence of letters forms a command, but
1138 several such commands can be run together without intervening
1139 whitespace. To separate them, use a regular expression in your
1145 </div></div>
1147 previous section.</p></div>
1150 version of some binary files. For example, a word processor
1151 document can be converted to an ASCII text representation, and
1152 the diff of the text shown. Even though this conversion loses
1153 some information, the resulting diff is useful for human
1154 viewing (but cannot be applied directly).</p></div>
1156 performing such a conversion. The program should take a single
1157 argument, the name of a file to convert, and produce the
1158 resulting text on stdout.</p></div>
1160 file instead of the binary information (assuming you have the
1161 exif tool installed), add the following section to your
1166 textconv = exif</tt></pre>
1167 </div></div>
1169 <table><tr>
1172 </td>
1174 in this example, we lose the actual image contents and focus
1175 just on the text data. This means that diffs generated by
1178 log, whatchanged, show) will perform text conversion. <tt>git
1179 format-patch</tt> will never generate this output. If you want to
1180 send somebody a text-converted diff of a binary file (e.g.,
1181 because it quickly conveys the changes you have made), you
1182 should generate it separately and send it as a comment <em>in
1184 </tr></table>
1185 </div>
1188 to cache the output and use it in future diffs. To enable
1190 config. For example:</p></div>
1194 textconv = exif
1195 cachetextconv = true</tt></pre>
1196 </div></div>
1198 indefinitely. If you change the textconv config variable for a
1199 diff driver, git will automatically invalidate the cache entries
1200 and re-run the textconv filter. If you want to invalidate the
1201 cache manually (e.g., because your version of "exif" was updated
1202 and now produces better output), you can remove the cache
1206 <div class="paragraph"><p>If you want to show differences between binary or specially-formatted
1207 blobs in your repository, you can choose to use either an external diff
1208 command, or to use textconv to convert them to a diff-able text format.
1209 Which method you choose depends on your exact situation.</p></div>
1210 <div class="paragraph"><p>The advantage of using an external diff command is flexibility. You are
1211 not bound to find line-oriented changes, nor is it necessary for the
1212 output to resemble unified diff. You are free to locate and report
1213 changes in the most appropriate way for your data format.</p></div>
1215 transformation of the data into a line-oriented text format, and git
1216 uses its regular diff tools to generate the output. There are several
1217 advantages to choosing this method:</p></div>
1219 <li>
1220 <p>
1221 Ease of use. It is often much simpler to write a binary to text
1222 transformation than it is to perform your own diff. In many cases,
1223 existing programs can be used as textconv filters (e.g., exif,
1224 odt2txt).
1225 </p>
1226 </li>
1227 <li>
1228 <p>
1229 Git diff features. By performing only the transformation step
1230 yourself, you can still utilize many of git’s diff features,
1231 including colorization, word-diff, and combined diffs for merges.
1232 </p>
1233 </li>
1234 <li>
1235 <p>
1236 Caching. Textconv caching can speed up repeated diffs, such as those
1238 </p>
1239 </li>
1240 </ol></div>
1243 data by examining the beginning of the contents. However, sometimes you
1244 may want to override its decision, either because a blob contains binary
1245 data later in the file, or because the content, while technically
1246 composed of text characters, is opaque to a human reader. For example,
1247 many postscript files contain only ascii characters, but produce noisy
1248 and meaningless diffs.</p></div>
1254 </div></div>
1255 <div class="paragraph"><p>This will cause git to generate <tt>Binary files differ</tt> (or a binary
1256 patch, if binary patches are enabled) instead of a regular diff.</p></div>
1257 <div class="paragraph"><p>However, one may also want to specify other diff driver attributes. For
1259 an ascii representation for human viewing, but otherwise treat them as
1265 textconv = ps2ascii
1266 binary = true</tt></pre>
1267 </div></div>
1268 <h3 id="_performing_a_three_way_merge">Performing a three-way merge</h3><div style="clear:left"></div>
1270 <div class="paragraph"><p>The attribute <tt>merge</tt> affects how three versions of a file are
1275 Set
1276 </dt>
1277 <dd>
1278 <p>
1279 Built-in 3-way merge driver is used to merge the
1281 suite. This is suitable for ordinary text files.
1282 </p>
1283 </dd>
1285 Unset
1286 </dt>
1287 <dd>
1288 <p>
1289 Take the version from the current branch as the
1290 tentative merge result, and declare that the merge has
1291 conflicts. This is suitable for binary files that do
1292 not have a well-defined merge semantics.
1293 </p>
1294 </dd>
1296 Unspecified
1297 </dt>
1298 <dd>
1299 <p>
1300 By default, this uses the same built-in 3-way merge
1303 different merge driver to be used with paths for which the
1305 </p>
1306 </dd>
1308 String
1309 </dt>
1310 <dd>
1311 <p>
1312 3-way merge is performed using the specified custom
1313 merge driver. The built-in 3-way merge driver can be
1314 explicitly specified by asking for "text" driver; the
1315 built-in "take the current branch" driver can be
1316 requested with "binary".
1317 </p>
1318 </dd>
1319 </dl></div>
1325 text
1326 </dt>
1327 <dd>
1328 <p>
1329 Usual 3-way file level merge for text files. Conflicted
1334 marker.
1335 </p>
1336 </dd>
1338 binary
1339 </dt>
1340 <dd>
1341 <p>
1342 Keep the version from your branch in the work tree, but
1343 leave the path in the conflicted state for the user to
1344 sort out.
1345 </p>
1346 </dd>
1348 union
1349 </dt>
1350 <dd>
1351 <p>
1352 Run 3-way file level merge for text files, but take
1353 lines from both versions, instead of leaving conflict
1354 markers. This tends to leave the added lines in the
1355 resulting file in random order and the user should
1356 verify the result. Do not use this if you do not
1357 understand the implications.
1358 </p>
1359 </dd>
1360 </dl></div>
1365 <div class="paragraph"><p>To define a custom merge driver <tt>filfre</tt>, add a section to your
1370 name = feel-free merge driver
1371 driver = filfre %O %A %B
1372 recursive = binary</tt></pre>
1373 </div></div>
1375 name.</p></div>
1376 <div class="paragraph"><p>The ‘merge.*.driver` variable’s value is used to construct a
1379 three tokens are replaced with the names of temporary files that
1380 hold the contents of these versions when the command line is
1381 built. Additionally, %L will be replaced with the conflict marker
1382 size (see below).</p></div>
1385 status if it managed to merge them cleanly, or non-zero if there
1386 were conflicts.</p></div>
1388 driver to use when the merge driver is called for an internal
1389 merge between common ancestors, when there are more than one.
1390 When left unspecified, the driver itself is used for both
1391 internal merge and the final merge.</p></div>
1394 the work tree file during a conflicted merge. Only setting to
1395 the value to a positive integer has any meaningful effect.</p></div>
1396 <div class="paragraph"><p>For example, this line in <tt>.gitattributes</tt> can be used to tell the merge
1397 machinery to leave much longer (instead of the usual 7-character-long)
1399 results in a conflict.</p></div>
1403 </div></div>
1404 <h3 id="_checking_whitespace_errors">Checking whitespace errors</h3><div style="clear:left"></div>
1406 <div class="paragraph"><p>The <tt>core.whitespace</tt> configuration variable allows you to define what
1409 control per path.</p></div>
1412 Set
1413 </dt>
1414 <dd>
1415 <p>
1416 Notice all types of potential whitespace errors known to git.
1418 configuration variable.
1419 </p>
1420 </dd>
1422 Unset
1423 </dt>
1424 <dd>
1425 <p>
1426 Do not notice anything as error.
1427 </p>
1428 </dd>
1430 Unspecified
1431 </dt>
1432 <dd>
1433 <p>
1435 decide what to notice as error.
1436 </p>
1437 </dd>
1439 String
1440 </dt>
1441 <dd>
1442 <p>
1443 Specify a comma separate list of common whitespace problems to
1445 variable.
1446 </p>
1447 </dd>
1448 </dl></div>
1451 <div class="paragraph"><p>Files and directories with the attribute <tt>export-ignore</tt> won’t be added to
1452 archive files.</p></div>
1454 <div class="paragraph"><p>If the attribute <tt>export-subst</tt> is set for a file then git will expand
1455 several placeholders when adding this file to an archive. The
1456 expansion depends on the availability of a commit ID, i.e., if
1458 tag then no replacement will be done. The placeholders are the same
1462 commit hash.</p></div>
1467 <h3 id="_viewing_files_in_gui_tools">Viewing files in GUI tools</h3><div style="clear:left"></div>
1469 <div class="paragraph"><p>The value of this attribute specifies the character encoding that should
1470 be used by GUI tools (e.g. <a href="gitk.html">gitk(1)</a> and <a href="git-gui.html">git-gui(1)</a>) to
1471 display the contents of the relevant file. Note that due to performance
1473 manually enable per-file encodings in its options.</p></div>
1474 <div class="paragraph"><p>If this attribute is not set or has an invalid value, the value of the
1477 </div>
1480 <div class="paragraph"><p>You do not want any end-of-line conversions applied to, nor textual diffs
1481 produced for, any binary file you track. You would need to specify e.g.</p></div>
1485 </div></div>
1487 macro attributes, you can define an attribute that, when set, also
1488 sets or unsets a number of other attributes at the same time. The
1493 </div></div>
1495 attributes as above. Note that macro attributes can only be "Set",
1496 though setting one might have the effect of setting or unsetting other
1497 attributes or even returning other attributes to the "Unspecified"
1498 state.</p></div>
1499 </div>
1502 <div class="paragraph"><p>Custom macro attributes can be defined only in the <tt>.gitattributes</tt>
1503 file at the toplevel (i.e. not in any subdirectory). The built-in
1508 </div></div>
1509 </div>
1515 <pre><tt>(in $GIT_DIR/info/attributes)
1517 a* foo !bar -baz
1519 (in .gitattributes)
1520 abc foo bar baz
1522 (in t/.gitattributes)
1523 ab* merge=filfre
1524 abc -foo -bar
1525 *.c frotz</tt></pre>
1526 </div></div>
1527 <div class="paragraph"><p>the attributes given to path <tt>t/abc</tt> are computed as follows:</p></div>
1529 <li>
1530 <p>
1532 directory as the path in question), git finds that the first
1535 are unset.
1536 </p>
1537 </li>
1538 <li>
1539 <p>
1541 directory), and finds that the first line matches, but
1545 </p>
1546 </li>
1547 <li>
1548 <p>
1550 is used to override the in-tree settings. The first line is
1553 </p>
1554 </li>
1555 </ol></div>
1556 <div class="paragraph"><p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p></div>
1559 <pre><tt>foo set to true
1560 bar unspecified
1561 baz set to false
1562 merge set to string value "filfre"
1563 frotz unspecified</tt></pre>
1564 </div></div>
1565 </div>
1569 </div>
1573 </div>
1574 </div>
1579 </div>
1580 </div>
1581 </body>
1582 </html>