| blob | 8df0fe024665234cae2cdda92801950fb8951e38 |
4 <head>
8 /* Debug borders */
10 /*
11 border: 1px solid red;
12 */
13 }
15 body {
17 }
19 a {
22 }
25 }
27 em {
29 }
31 strong {
33 }
35 tt {
37 }
45 }
49 }
50 h2 {
52 }
53 h3 {
55 }
56 h3 + * {
58 }
63 }
65 hr {
67 }
69 p {
72 }
74 pre {
77 }
79 span#author {
84 }
85 span#email {
86 }
87 span#revision {
89 }
91 div#footer {
97 }
98 div#footer-text {
101 }
102 div#footer-badges {
105 }
107 div#preamble,
114 }
118 }
122 }
124 /* Block element titles. */
131 }
134 }
138 }
141 }
144 }
150 }
154 }
159 }
163 }
167 }
170 }
179 }
183 }
188 }
192 }
198 dl {
201 }
202 dt {
206 }
209 }
213 }
216 }
220 }
221 thead {
224 }
225 tfoot {
227 }
232 }
235 }
240 }
243 }
247 }
249 div#toctitle {
256 }
261 }
265 }
269 }
273 }
275 /* Workarounds for IE6's broken and incomplete CSS2. */
281 }
287 }
293 }
297 }
302 }
304 /* IE6 sets dynamically generated links as visited. */
306 </style>
308 </head>
309 <body>
311 <h1>
312 gitattributes(5) Manual Page
313 </h1>
316 <p>gitattributes -
317 defining attributes per path
318 </p>
319 </div>
320 </div>
324 </div>
333 </div></div>
335 separated by whitespaces. When the pattern matches the
336 path in question, the attributes listed on the line are given to
337 the path.</p></div>
340 <dt>
341 Set
342 </dt>
343 <dd>
344 <p>
345 The path has the attribute with special value "true";
346 this is specified by listing only the name of the
347 attribute in the attribute list.
348 </p>
349 </dd>
350 <dt>
351 Unset
352 </dt>
353 <dd>
354 <p>
355 The path has the attribute with special value "false";
356 this is specified by listing the name of the attribute
358 </p>
359 </dd>
360 <dt>
361 Set to a value
362 </dt>
363 <dd>
364 <p>
365 The path has the attribute with specified string value;
366 this is specified by listing the name of the attribute
368 attribute list.
369 </p>
370 </dd>
371 <dt>
372 Unspecified
373 </dt>
374 <dd>
375 <p>
376 No pattern matches the path, and nothing says if
377 the path has or does not have the attribute, the
378 attribute for the path is said to be Unspecified.
379 </p>
380 </dd>
381 </dl></div>
383 overrides an earlier line. This overriding is done per
384 attribute. The rules how the pattern matches paths are the
389 path in question, and its parent directories up to the toplevel of the
391 is from the path in question, the lower its precedence).</p></div>
393 attributes to files that are particular to one user's workflow), then
395 Attributes which should be version-controlled and distributed to other
396 repositories (i.e., attributes of interest to all users) should go into
401 </div>
405 particular attributes to a path. Currently, the following
406 operations are attributes-aware.</p></div>
407 <h3 id="_checking_out_and_checking_in">Checking-out and checking-in</h3><div style="clear:left"></div>
409 repository are copied to the working tree files when commands
411 git stores the contents you prepare in the working tree in the
415 text file is normalized, its line endings are converted to LF in the
416 repository. To control what line ending style is used in the working
420 <dt>
421 Set
422 </dt>
423 <dd>
424 <p>
426 normalization and marks the path as a text file. End-of-line
427 conversion takes place without guessing the content type.
428 </p>
429 </dd>
430 <dt>
431 Unset
432 </dt>
433 <dd>
434 <p>
436 attempt any end-of-line conversion upon checkin or checkout.
437 </p>
438 </dd>
439 <dt>
440 Set to string value "auto"
441 </dt>
442 <dd>
443 <p>
445 end-of-line normalization. If git decides that the content is
446 text, its line endings are normalized to LF on checkin.
447 </p>
448 </dd>
449 <dt>
450 Unspecified
451 </dt>
452 <dd>
453 <p>
456 file should be converted.
457 </p>
458 </dd>
459 </dl></div>
461 unspecified.</p></div>
464 working directory. It enables end-of-line normalization without any
467 <dt>
468 Set to string value "crlf"
469 </dt>
470 <dd>
471 <p>
472 This setting forces git to normalize line endings for this
473 file on checkin and convert them to CRLF when the file is
474 checked out.
475 </p>
476 </dd>
477 <dt>
478 Set to string value "lf"
479 </dt>
480 <dd>
481 <p>
482 This setting forces git to normalize line endings to LF on
483 checkin and prevents conversion to CRLF when the file is
484 checked out.
485 </p>
486 </dd>
487 </dl></div>
488 <h4 id="_backwards_compatibility_with_tt_crlf_tt_attribute">Backwards compatibility with <tt>crlf</tt> attribute</h4>
490 follows:</p></div>
493 <pre><tt>crlf text
494 -crlf -text
495 crlf=input eol=lf</tt></pre>
496 </div></div>
499 normalize line endings to LF in the repository and, optionally, to
500 convert them to CRLF when files are checked out.</p></div>
502 files, ensure that .vcproj files have CRLF and .sh files have LF in
503 the working directory, and prevent .jpg files from being normalized
504 regardless of their content.</p></div>
507 <pre><tt>*.txt text
508 *.vcproj eol=crlf
509 *.sh eol=lf
510 *.jpg -text</tt></pre>
511 </div></div>
513 repositories, and there are two ways to enable similar automatic
514 normalization in git.</p></div>
516 regardless of the repository you are working with, you can set the
520 <pre><tt>[core]
521 autocrlf = true</tt></pre>
522 </div></div>
524 that text files that you introduce to the repository have their line
525 endings normalized to LF when they are added, and that files that are
526 already normalized in the repository stay normalized.</p></div>
528 enforces end-of-line normalization, or you simply want all text files
534 </div></div>
537 configuration variable controls which line endings git will use for
538 normalized files in your working directory; the default is to use the
540 set.</p></div>
542 <table><tr>
545 </td>
547 repository, any text files containing CRLFs should be normalized. If
548 they are not they will be normalized the next time someone tries to
549 change them, causing unfortunate misattribution. From a clean working
550 directory:</td>
551 </tr></table>
552 </div>
556 $ rm .git/index # Remove the index to force git to
557 $ git reset # re-scan the working directory
558 $ git status # Show files that will be normalized
559 $ git add -u
560 $ git add .gitattributes
562 </div></div>
568 </div></div>
570 enabled manually.</p></div>
574 </div></div>
576 the conversion is reversible for the current setting of
578 conversions; for "warn", git only prints a warning but accepts
579 an irreversible conversion. The safety triggers to prevent such
580 a conversion done to the files in the work tree, but there are a
583 <li>
584 <p>
586 next checkout would, so the safety triggers;
587 </p>
588 </li>
589 <li>
590 <p>
592 in the work tree, but the operation is about text files and CRLF
593 conversion is about fixing the line ending inconsistencies, so the
594 safety does not trigger;
595 </p>
596 </li>
597 <li>
598 <p>
601 catch potential problems early, safety triggers.
602 </p>
603 </li>
604 </ul></div>
608 40-character hexadecimal blob object name, followed by a dollar
614 filter driver specified in the configuration.</p></div>
616 command, either of which can be left unspecified. Upon
618 fed the blob object from its standard input, and its standard
619 output is used to update the worktree file. Similarly, the
621 upon checkin.</p></div>
623 but makes the filter a no-op passthru.</p></div>
625 shape that is more convenient for the platform, filesystem, and
626 the user to use. The key phrase here is "more convenient" and not
627 "turning something unusable into usable". In other words, the
628 intent is that if someone unsets the filter driver definition,
629 or does not have the appropriate filter program, the project
630 should still be usable.</p></div>
632 attribute for paths.</p></div>
636 </div></div>
638 configuration in your .git/config to specify a pair of commands to
639 modify the contents of C programs when the source files are checked
640 in ("clean" is run) and checked out (no change is made because the
645 clean = indent
646 smudge = cat</tt></pre>
647 </div></div>
648 <div class="para"><p>For best results, <tt>clean</tt> should not alter its output further if it is
652 section on merging below.</p></div>
654 input that is already correctly indented. In this case, the lack of a
655 smudge filter means that the clean filter _must_ accept its own output
656 without modifying it.</p></div>
657 <h4 id="_interaction_between_checkin_checkout_attributes">Interaction between checkin/checkout attributes</h4>
662 and applicable).</p></div>
665 <h4 id="_merging_branches_with_differing_checkin_checkout_attributes">Merging branches with differing checkin/checkout attributes</h4>
667 repository format for that file to change, such as adding a
668 clean/smudge filter or text/eol/ident attributes, merging anything
669 where the attribute is not in place would normally cause merge
670 conflicts.</p></div>
672 virtual check-out and check-in of all three stages of a file when
674 configuration variable. This prevents changes caused by check-in
675 conversion from causing spurious merge conflicts when a converted file
676 is merged with an unconverted file.</p></div>
678 even on files that are already smudged, this strategy will
679 automatically resolve all filter-related conflicts. Filters that do
680 not act in this way may cause additional merge conflicts that must be
681 resolved manually.</p></div>
684 <div class="para"><p>The attribute <tt>diff</tt> affects how <em>git</em> generates diffs for particular
685 files. It can tell git whether to generate a textual patch for the path
686 or to treat the path as a binary file. It can also affect what line is
688 external command to generate the diff, or ask git to convert binary
689 files to a text format before generating the diff.</p></div>
691 <dt>
692 Set
693 </dt>
694 <dd>
695 <p>
697 as text, even when they contain byte values that
698 normally never appear in text files, such as NUL.
699 </p>
700 </dd>
701 <dt>
702 Unset
703 </dt>
704 <dd>
705 <p>
708 binary patches are enabled).
709 </p>
710 </dd>
711 <dt>
712 Unspecified
713 </dt>
714 <dd>
715 <p>
717 first gets its contents inspected, and if it looks like
718 text, it is treated as text. Otherwise it would
720 </p>
721 </dd>
722 <dt>
723 String
724 </dt>
725 <dd>
726 <p>
727 Diff is shown using the specified diff driver. Each driver may
728 specify one or more options, as described in the following
729 section. The options for the diff driver "foo" are defined
730 by the configuration variables in the "diff.foo" section of the
731 git config file.
732 </p>
733 </dd>
734 </dl></div>
744 command = j-c-diff</tt></pre>
745 </div></div>
753 is prefixed with a line of the form:</p></div>
757 </div></div>
758 <div class="para"><p>This is called a <em>hunk header</em>. The "TEXT" portion is by default a line
759 that begins with an alphabet, an underscore or a dollar sign; this
761 is not suited for some contents, and you can use a customized pattern
762 to make a selection.</p></div>
764 for paths.</p></div>
768 </div></div>
770 specify a regular expression that matches a line that you would
771 want to appear as the hunk header "TEXT". Add a section to your
777 </div></div>
779 configuration file parser, so you would need to double the
780 backslashes; the pattern above picks a line that begins with a
784 is one of them, so you do not have to write the above in your
785 configuration file (you still need to enable this with the
787 patterns are available:</p></div>
789 <li>
790 <p>
792 </p>
793 </li>
794 <li>
795 <p>
797 </p>
798 </li>
799 <li>
800 <p>
802 </p>
803 </li>
804 <li>
805 <p>
807 </p>
808 </li>
809 <li>
810 <p>
812 </p>
813 </li>
814 <li>
815 <p>
817 </p>
818 </li>
819 <li>
820 <p>
822 </p>
823 </li>
824 <li>
825 <p>
827 </p>
828 </li>
829 <li>
830 <p>
832 </p>
833 </li>
834 <li>
835 <p>
837 </p>
838 </li>
839 <li>
840 <p>
842 </p>
843 </li>
844 </ul></div>
847 split words in a line, by specifying an appropriate regular expression
848 in the "diff.*.wordRegex" configuration variable. For example, in TeX
849 a backslash followed by a sequence of letters forms a command, but
850 several such commands can be run together without intervening
851 whitespace. To separate them, use a regular expression in your
857 </div></div>
859 previous section.</p></div>
862 version of some binary files. For example, a word processor
863 document can be converted to an ASCII text representation, and
864 the diff of the text shown. Even though this conversion loses
865 some information, the resulting diff is useful for human
866 viewing (but cannot be applied directly).</p></div>
868 performing such a conversion. The program should take a single
869 argument, the name of a file to convert, and produce the
870 resulting text on stdout.</p></div>
872 file instead of the binary information (assuming you have the
873 exif tool installed), add the following section to your
878 textconv = exif</tt></pre>
879 </div></div>
881 <table><tr>
884 </td>
886 in this example, we lose the actual image contents and focus
887 just on the text data. This means that diffs generated by
888 textconv are _not_ suitable for applying. For this reason,
890 log, whatchanged, show) will perform text conversion. <tt>git
891 format-patch</tt> will never generate this output. If you want to
892 send somebody a text-converted diff of a binary file (e.g.,
893 because it quickly conveys the changes you have made), you
894 should generate it separately and send it as a comment _in
895 addition to_ the usual binary diff that you might send.</td>
896 </tr></table>
897 </div>
900 to cache the output and use it in future diffs. To enable
901 caching, set the "cachetextconv" variable in your diff driver's
902 config. For example:</p></div>
906 textconv = exif
907 cachetextconv = true</tt></pre>
908 </div></div>
910 indefinitely. If you change the textconv config variable for a
911 diff driver, git will automatically invalidate the cache entries
912 and re-run the textconv filter. If you want to invalidate the
913 cache manually (e.g., because your version of "exif" was updated
914 and now produces better output), you can remove the cache
917 <h3 id="_performing_a_three_way_merge">Performing a three-way merge</h3><div style="clear:left"></div>
923 <dt>
924 Set
925 </dt>
926 <dd>
927 <p>
928 Built-in 3-way merge driver is used to merge the
930 suite. This is suitable for ordinary text files.
931 </p>
932 </dd>
933 <dt>
934 Unset
935 </dt>
936 <dd>
937 <p>
938 Take the version from the current branch as the
939 tentative merge result, and declare that the merge has
940 conflicts. This is suitable for binary files that does
941 not have a well-defined merge semantics.
942 </p>
943 </dd>
944 <dt>
945 Unspecified
946 </dt>
947 <dd>
948 <p>
949 By default, this uses the same built-in 3-way merge
952 different merge driver to be used for paths to which the
954 </p>
955 </dd>
956 <dt>
957 String
958 </dt>
959 <dd>
960 <p>
961 3-way merge is performed using the specified custom
962 merge driver. The built-in 3-way merge driver can be
963 explicitly specified by asking for "text" driver; the
964 built-in "take the current branch" driver can be
965 requested with "binary".
966 </p>
967 </dd>
968 </dl></div>
973 <dt>
974 text
975 </dt>
976 <dd>
977 <p>
978 Usual 3-way file level merge for text files. Conflicted
983 marker.
984 </p>
985 </dd>
986 <dt>
987 binary
988 </dt>
989 <dd>
990 <p>
991 Keep the version from your branch in the work tree, but
992 leave the path in the conflicted state for the user to
993 sort out.
994 </p>
995 </dd>
996 <dt>
997 union
998 </dt>
999 <dd>
1000 <p>
1001 Run 3-way file level merge for text files, but take
1002 lines from both versions, instead of leaving conflict
1003 markers. This tends to leave the added lines in the
1004 resulting file in random order and the user should
1005 verify the result. Do not use this if you do not
1006 understand the implications.
1007 </p>
1008 </dd>
1009 </dl></div>
1019 name = feel-free merge driver
1020 driver = filfre %O %A %B
1021 recursive = binary</tt></pre>
1022 </div></div>
1024 name.</p></div>
1028 three tokens are replaced with the names of temporary files that
1029 hold the contents of these versions when the command line is
1030 built. Additionally, %L will be replaced with the conflict marker
1031 size (see below).</p></div>
1034 status if it managed to merge them cleanly, or non-zero if there
1035 were conflicts.</p></div>
1037 driver to use when the merge driver is called for an internal
1038 merge between common ancestors, when there are more than one.
1039 When left unspecified, the driver itself is used for both
1040 internal merge and the final merge.</p></div>
1043 the work tree file during a conflicted merge. Only setting to
1044 the value to a positive integer has any meaningful effect.</p></div>
1045 <div class="para"><p>For example, this line in <tt>.gitattributes</tt> can be used to tell the merge
1046 machinery to leave much longer (instead of the usual 7-character-long)
1048 results in a conflict.</p></div>
1052 </div></div>
1053 <h3 id="_checking_whitespace_errors">Checking whitespace errors</h3><div style="clear:left"></div>
1055 <div class="para"><p>The <tt>core.whitespace</tt> configuration variable allows you to define what
1058 control per path.</p></div>
1060 <dt>
1061 Set
1062 </dt>
1063 <dd>
1064 <p>
1065 Notice all types of potential whitespace errors known to git.
1066 </p>
1067 </dd>
1068 <dt>
1069 Unset
1070 </dt>
1071 <dd>
1072 <p>
1073 Do not notice anything as error.
1074 </p>
1075 </dd>
1076 <dt>
1077 Unspecified
1078 </dt>
1079 <dd>
1080 <p>
1082 decide what to notice as error.
1083 </p>
1084 </dd>
1085 <dt>
1086 String
1087 </dt>
1088 <dd>
1089 <p>
1090 Specify a comma separate list of common whitespace problems to
1092 variable.
1093 </p>
1094 </dd>
1095 </dl></div>
1098 <div class="para"><p>Files and directories with the attribute <tt>export-ignore</tt> won't be added to
1099 archive files.</p></div>
1101 <div class="para"><p>If the attribute <tt>export-subst</tt> is set for a file then git will expand
1102 several placeholders when adding this file to an archive. The
1103 expansion depends on the availability of a commit ID, i.e., if
1105 tag then no replacement will be done. The placeholders are the same
1109 commit hash.</p></div>
1114 <h3 id="_viewing_files_in_gui_tools">Viewing files in GUI tools</h3><div style="clear:left"></div>
1117 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
1118 display the contents of the relevant file. Note that due to performance
1120 manually enable per-file encodings in its options.</p></div>
1124 </div>
1128 produced for, any binary file you track. You would need to specify e.g.</p></div>
1132 </div></div>
1134 attribute macros, you can specify groups of attributes set or unset at
1139 </div></div>
1143 </div>
1146 <div class="para"><p>Custom attribute macros can be defined only in the <tt>.gitattributes</tt> file
1147 at the toplevel (i.e. not in any subdirectory). The built-in attribute
1152 </div></div>
1153 </div>
1159 <pre><tt>(in $GIT_DIR/info/attributes)
1161 a* foo !bar -baz
1163 (in .gitattributes)
1164 abc foo bar baz
1166 (in t/.gitattributes)
1167 ab* merge=filfre
1168 abc -foo -bar
1169 *.c frotz</tt></pre>
1170 </div></div>
1171 <div class="para"><p>the attributes given to path <tt>t/abc</tt> are computed as follows:</p></div>
1173 <li>
1174 <p>
1176 directory as the path in question), git finds that the first
1179 are unset.
1180 </p>
1181 </li>
1182 <li>
1183 <p>
1185 directory), and finds that the first line matches, but
1189 </p>
1190 </li>
1191 <li>
1192 <p>
1194 is used to override the in-tree settings. The first line is
1197 </p>
1198 </li>
1199 </ol></div>
1200 <div class="para"><p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p></div>
1203 <pre><tt>foo set to true
1204 bar unspecified
1205 baz set to false
1206 merge set to string value "filfre"
1207 frotz unspecified</tt></pre>
1208 </div></div>
1209 </div>
1213 </div>
1217 </div>
1218 </div>
1219 </body>
1220 </html>