| blob | fe9bd81f3d7e95cc0f8897a969d5acd1d45ff0f4 |
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 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 gitattributes(5) Manual Page
407 </h1>
410 <p>gitattributes -
411 defining attributes per path
412 </p>
413 </div>
414 </div>
418 </div>
427 </div></div>
429 separated by whitespaces. When the pattern matches the
430 path in question, the attributes listed on the line are given to
431 the path.</p></div>
432 <div class="paragraph"><p>Each attribute can be in one of these states for a given path:</p></div>
435 Set
436 </dt>
437 <dd>
438 <p>
439 The path has the attribute with special value "true";
440 this is specified by listing only the name of the
441 attribute in the attribute list.
442 </p>
443 </dd>
445 Unset
446 </dt>
447 <dd>
448 <p>
449 The path has the attribute with special value "false";
450 this is specified by listing the name of the attribute
452 </p>
453 </dd>
455 Set to a value
456 </dt>
457 <dd>
458 <p>
459 The path has the attribute with specified string value;
460 this is specified by listing the name of the attribute
462 attribute list.
463 </p>
464 </dd>
466 Unspecified
467 </dt>
468 <dd>
469 <p>
470 No pattern matches the path, and nothing says if
471 the path has or does not have the attribute, the
472 attribute for the path is said to be Unspecified.
473 </p>
474 </dd>
475 </dl></div>
477 overrides an earlier line. This overriding is done per
478 attribute. The rules how the pattern matches paths are the
483 path in question, and its parent directories up to the toplevel of the
485 is from the path in question, the lower its precedence). Finally
486 global and system-wide files are considered (they have the lowest
487 precedence).</p></div>
489 attributes to files that are particular to
490 one user’s workflow for that repository), then
492 Attributes which should be version-controlled and distributed to other
493 repositories (i.e., attributes of interest to all users) should go into
495 for a single user should be placed in a file specified by the
496 <tt>core.attributesfile</tt> configuration option (see <a href="git-config.html">git-config(1)</a>).
497 Attributes for all users on a system should be placed in the
502 </div>
506 particular attributes to a path. Currently, the following
507 operations are attributes-aware.</p></div>
508 <h3 id="_checking_out_and_checking_in">Checking-out and checking-in</h3><div style="clear:left"></div>
510 repository are copied to the working tree files when commands
512 git stores the contents you prepare in the working tree in the
516 text file is normalized, its line endings are converted to LF in the
517 repository. To control what line ending style is used in the working
522 Set
523 </dt>
524 <dd>
525 <p>
527 normalization and marks the path as a text file. End-of-line
528 conversion takes place without guessing the content type.
529 </p>
530 </dd>
532 Unset
533 </dt>
534 <dd>
535 <p>
537 attempt any end-of-line conversion upon checkin or checkout.
538 </p>
539 </dd>
541 Set to string value "auto"
542 </dt>
543 <dd>
544 <p>
546 end-of-line normalization. If git decides that the content is
547 text, its line endings are normalized to LF on checkin.
548 </p>
549 </dd>
551 Unspecified
552 </dt>
553 <dd>
554 <p>
557 file should be converted.
558 </p>
559 </dd>
560 </dl></div>
562 unspecified.</p></div>
565 working directory. It enables end-of-line normalization without any
569 Set to string value "crlf"
570 </dt>
571 <dd>
572 <p>
573 This setting forces git to normalize line endings for this
574 file on checkin and convert them to CRLF when the file is
575 checked out.
576 </p>
577 </dd>
579 Set to string value "lf"
580 </dt>
581 <dd>
582 <p>
583 This setting forces git to normalize line endings to LF on
584 checkin and prevents conversion to CRLF when the file is
585 checked out.
586 </p>
587 </dd>
588 </dl></div>
589 <h4 id="_backwards_compatibility_with_tt_crlf_tt_attribute">Backwards compatibility with <tt>crlf</tt> attribute</h4>
590 <div class="paragraph"><p>For backwards compatibility, the <tt>crlf</tt> attribute is interpreted as
591 follows:</p></div>
594 <pre><tt>crlf text
595 -crlf -text
596 crlf=input eol=lf</tt></pre>
597 </div></div>
599 <div class="paragraph"><p>While git normally leaves file contents alone, it can be configured to
600 normalize line endings to LF in the repository and, optionally, to
601 convert them to CRLF when files are checked out.</p></div>
603 files, ensure that .vcproj files have CRLF and .sh files have LF in
604 the working directory, and prevent .jpg files from being normalized
605 regardless of their content.</p></div>
608 <pre><tt>*.txt text
609 *.vcproj eol=crlf
610 *.sh eol=lf
611 *.jpg -text</tt></pre>
612 </div></div>
613 <div class="paragraph"><p>Other source code management systems normalize all text files in their
614 repositories, and there are two ways to enable similar automatic
615 normalization in git.</p></div>
616 <div class="paragraph"><p>If you simply want to have CRLF line endings in your working directory
617 regardless of the repository you are working with, you can set the
621 <pre><tt>[core]
622 autocrlf = true</tt></pre>
623 </div></div>
625 that text files that you introduce to the repository have their line
626 endings normalized to LF when they are added, and that files that are
627 already normalized in the repository stay normalized.</p></div>
629 enforces end-of-line normalization, or you simply want all text files
635 </div></div>
638 configuration variable controls which line endings git will use for
639 normalized files in your working directory; the default is to use the
641 set.</p></div>
643 <table><tr>
646 </td>
648 repository, any text files containing CRLFs should be normalized. If
649 they are not they will be normalized the next time someone tries to
650 change them, causing unfortunate misattribution. From a clean working
651 directory:</td>
652 </tr></table>
653 </div>
657 $ rm .git/index # Remove the index to force git to
658 $ git reset # re-scan the working directory
659 $ git status # Show files that will be normalized
660 $ git add -u
661 $ git add .gitattributes
663 </div></div>
664 <div class="paragraph"><p>If any files that should not be normalized show up in <em>git status</em>,
669 </div></div>
670 <div class="paragraph"><p>Conversely, text files that git does not detect can have normalization
671 enabled manually.</p></div>
675 </div></div>
677 the conversion is reversible for the current setting of
679 conversions; for "warn", git only prints a warning but accepts
680 an irreversible conversion. The safety triggers to prevent such
681 a conversion done to the files in the work tree, but there are a
684 <li>
685 <p>
687 next checkout would, so the safety triggers;
688 </p>
689 </li>
690 <li>
691 <p>
693 in the work tree, but the operation is about text files and CRLF
694 conversion is about fixing the line ending inconsistencies, so the
695 safety does not trigger;
696 </p>
697 </li>
698 <li>
699 <p>
702 catch potential problems early, safety triggers.
703 </p>
704 </li>
705 </ul></div>
709 40-character hexadecimal blob object name, followed by a dollar
715 filter driver specified in the configuration.</p></div>
716 <div class="paragraph"><p>A filter driver consists of a <tt>clean</tt> command and a <tt>smudge</tt>
717 command, either of which can be left unspecified. Upon
719 fed the blob object from its standard input, and its standard
720 output is used to update the worktree file. Similarly, the
722 upon checkin.</p></div>
724 but makes the filter a no-op passthru.</p></div>
726 shape that is more convenient for the platform, filesystem, and
727 the user to use. The key phrase here is "more convenient" and not
728 "turning something unusable into usable". In other words, the
729 intent is that if someone unsets the filter driver definition,
730 or does not have the appropriate filter program, the project
731 should still be usable.</p></div>
733 attribute for paths.</p></div>
737 </div></div>
738 <div class="paragraph"><p>Then you would define a "filter.indent.clean" and "filter.indent.smudge"
739 configuration in your .git/config to specify a pair of commands to
740 modify the contents of C programs when the source files are checked
741 in ("clean" is run) and checked out (no change is made because the
746 clean = indent
747 smudge = cat</tt></pre>
748 </div></div>
749 <div class="paragraph"><p>For best results, <tt>clean</tt> should not alter its output further if it is
753 section on merging below.</p></div>
754 <div class="paragraph"><p>The "indent" filter is well-behaved in this regard: it will not modify
755 input that is already correctly indented. In this case, the lack of a
757 without modifying it.</p></div>
759 the file the filter is working on. A filter might use this in keyword
760 substitution. For example:</p></div>
764 clean = git-p4-filter --clean %f
765 smudge = git-p4-filter --smudge %f</tt></pre>
766 </div></div>
767 <h4 id="_interaction_between_checkin_checkout_attributes">Interaction between checkin/checkout attributes</h4>
772 and applicable).</p></div>
775 <h4 id="_merging_branches_with_differing_checkin_checkout_attributes">Merging branches with differing checkin/checkout attributes</h4>
777 repository format for that file to change, such as adding a
778 clean/smudge filter or text/eol/ident attributes, merging anything
779 where the attribute is not in place would normally cause merge
780 conflicts.</p></div>
781 <div class="paragraph"><p>To prevent these unnecessary merge conflicts, git can be told to run a
782 virtual check-out and check-in of all three stages of a file when
784 configuration variable. This prevents changes caused by check-in
785 conversion from causing spurious merge conflicts when a converted file
786 is merged with an unconverted file.</p></div>
787 <div class="paragraph"><p>As long as a "smudge→clean" results in the same output as a "clean"
788 even on files that are already smudged, this strategy will
789 automatically resolve all filter-related conflicts. Filters that do
790 not act in this way may cause additional merge conflicts that must be
791 resolved manually.</p></div>
794 <div class="paragraph"><p>The attribute <tt>diff</tt> affects how <em>git</em> generates diffs for particular
795 files. It can tell git whether to generate a textual patch for the path
796 or to treat the path as a binary file. It can also affect what line is
798 external command to generate the diff, or ask git to convert binary
799 files to a text format before generating the diff.</p></div>
802 Set
803 </dt>
804 <dd>
805 <p>
807 as text, even when they contain byte values that
808 normally never appear in text files, such as NUL.
809 </p>
810 </dd>
812 Unset
813 </dt>
814 <dd>
815 <p>
818 binary patches are enabled).
819 </p>
820 </dd>
822 Unspecified
823 </dt>
824 <dd>
825 <p>
827 first gets its contents inspected, and if it looks like
828 text, it is treated as text. Otherwise it would
830 </p>
831 </dd>
833 String
834 </dt>
835 <dd>
836 <p>
837 Diff is shown using the specified diff driver. Each driver may
838 specify one or more options, as described in the following
839 section. The options for the diff driver "foo" are defined
840 by the configuration variables in the "diff.foo" section of the
841 git config file.
842 </p>
843 </dd>
844 </dl></div>
849 <div class="paragraph"><p>To define an external diff driver <tt>jcdiff</tt>, add a section to your
854 command = j-c-diff</tt></pre>
855 </div></div>
863 is prefixed with a line of the form:</p></div>
867 </div></div>
868 <div class="paragraph"><p>This is called a <em>hunk header</em>. The "TEXT" portion is by default a line
869 that begins with an alphabet, an underscore or a dollar sign; this
871 is not suited for some contents, and you can use a customized pattern
872 to make a selection.</p></div>
873 <div class="paragraph"><p>First, in .gitattributes, you would assign the <tt>diff</tt> attribute
874 for paths.</p></div>
878 </div></div>
880 specify a regular expression that matches a line that you would
881 want to appear as the hunk header "TEXT". Add a section to your
887 </div></div>
889 configuration file parser, so you would need to double the
890 backslashes; the pattern above picks a line that begins with a
893 <div class="paragraph"><p>There are a few built-in patterns to make this easier, and <tt>tex</tt>
894 is one of them, so you do not have to write the above in your
895 configuration file (you still need to enable this with the
897 patterns are available:</p></div>
899 <li>
900 <p>
902 </p>
903 </li>
904 <li>
905 <p>
907 </p>
908 </li>
909 <li>
910 <p>
912 </p>
913 </li>
914 <li>
915 <p>
917 </p>
918 </li>
919 <li>
920 <p>
922 </p>
923 </li>
924 <li>
925 <p>
927 </p>
928 </li>
929 <li>
930 <p>
932 </p>
933 </li>
934 <li>
935 <p>
937 </p>
938 </li>
939 <li>
940 <p>
942 </p>
943 </li>
944 <li>
945 <p>
947 </p>
948 </li>
949 <li>
950 <p>
952 </p>
953 </li>
954 <li>
955 <p>
957 </p>
958 </li>
959 <li>
960 <p>
962 </p>
963 </li>
964 </ul></div>
966 <div class="paragraph"><p>You can customize the rules that <tt>git diff --word-diff</tt> uses to
967 split words in a line, by specifying an appropriate regular expression
968 in the "diff.*.wordRegex" configuration variable. For example, in TeX
969 a backslash followed by a sequence of letters forms a command, but
970 several such commands can be run together without intervening
971 whitespace. To separate them, use a regular expression in your
977 </div></div>
979 previous section.</p></div>
982 version of some binary files. For example, a word processor
983 document can be converted to an ASCII text representation, and
984 the diff of the text shown. Even though this conversion loses
985 some information, the resulting diff is useful for human
986 viewing (but cannot be applied directly).</p></div>
988 performing such a conversion. The program should take a single
989 argument, the name of a file to convert, and produce the
990 resulting text on stdout.</p></div>
992 file instead of the binary information (assuming you have the
993 exif tool installed), add the following section to your
998 textconv = exif</tt></pre>
999 </div></div>
1001 <table><tr>
1004 </td>
1006 in this example, we lose the actual image contents and focus
1007 just on the text data. This means that diffs generated by
1010 log, whatchanged, show) will perform text conversion. <tt>git
1011 format-patch</tt> will never generate this output. If you want to
1012 send somebody a text-converted diff of a binary file (e.g.,
1013 because it quickly conveys the changes you have made), you
1014 should generate it separately and send it as a comment <em>in
1016 </tr></table>
1017 </div>
1020 to cache the output and use it in future diffs. To enable
1022 config. For example:</p></div>
1026 textconv = exif
1027 cachetextconv = true</tt></pre>
1028 </div></div>
1030 indefinitely. If you change the textconv config variable for a
1031 diff driver, git will automatically invalidate the cache entries
1032 and re-run the textconv filter. If you want to invalidate the
1033 cache manually (e.g., because your version of "exif" was updated
1034 and now produces better output), you can remove the cache
1038 <div class="paragraph"><p>If you want to show differences between binary or specially-formatted
1039 blobs in your repository, you can choose to use either an external diff
1040 command, or to use textconv to convert them to a diff-able text format.
1041 Which method you choose depends on your exact situation.</p></div>
1042 <div class="paragraph"><p>The advantage of using an external diff command is flexibility. You are
1043 not bound to find line-oriented changes, nor is it necessary for the
1044 output to resemble unified diff. You are free to locate and report
1045 changes in the most appropriate way for your data format.</p></div>
1047 transformation of the data into a line-oriented text format, and git
1048 uses its regular diff tools to generate the output. There are several
1049 advantages to choosing this method:</p></div>
1051 <li>
1052 <p>
1053 Ease of use. It is often much simpler to write a binary to text
1054 transformation than it is to perform your own diff. In many cases,
1055 existing programs can be used as textconv filters (e.g., exif,
1056 odt2txt).
1057 </p>
1058 </li>
1059 <li>
1060 <p>
1061 Git diff features. By performing only the transformation step
1062 yourself, you can still utilize many of git’s diff features,
1063 including colorization, word-diff, and combined diffs for merges.
1064 </p>
1065 </li>
1066 <li>
1067 <p>
1068 Caching. Textconv caching can speed up repeated diffs, such as those
1070 </p>
1071 </li>
1072 </ol></div>
1075 data by examining the beginning of the contents. However, sometimes you
1076 may want to override its decision, either because a blob contains binary
1077 data later in the file, or because the content, while technically
1078 composed of text characters, is opaque to a human reader. For example,
1079 many postscript files contain only ascii characters, but produce noisy
1080 and meaningless diffs.</p></div>
1086 </div></div>
1087 <div class="paragraph"><p>This will cause git to generate <tt>Binary files differ</tt> (or a binary
1088 patch, if binary patches are enabled) instead of a regular diff.</p></div>
1089 <div class="paragraph"><p>However, one may also want to specify other diff driver attributes. For
1091 an ascii representation for human viewing, but otherwise treat them as
1097 textconv = ps2ascii
1098 binary = true</tt></pre>
1099 </div></div>
1100 <h3 id="_performing_a_three_way_merge">Performing a three-way merge</h3><div style="clear:left"></div>
1102 <div class="paragraph"><p>The attribute <tt>merge</tt> affects how three versions of a file are
1107 Set
1108 </dt>
1109 <dd>
1110 <p>
1111 Built-in 3-way merge driver is used to merge the
1113 suite. This is suitable for ordinary text files.
1114 </p>
1115 </dd>
1117 Unset
1118 </dt>
1119 <dd>
1120 <p>
1121 Take the version from the current branch as the
1122 tentative merge result, and declare that the merge has
1123 conflicts. This is suitable for binary files that do
1124 not have a well-defined merge semantics.
1125 </p>
1126 </dd>
1128 Unspecified
1129 </dt>
1130 <dd>
1131 <p>
1132 By default, this uses the same built-in 3-way merge
1135 different merge driver to be used with paths for which the
1137 </p>
1138 </dd>
1140 String
1141 </dt>
1142 <dd>
1143 <p>
1144 3-way merge is performed using the specified custom
1145 merge driver. The built-in 3-way merge driver can be
1146 explicitly specified by asking for "text" driver; the
1147 built-in "take the current branch" driver can be
1148 requested with "binary".
1149 </p>
1150 </dd>
1151 </dl></div>
1157 text
1158 </dt>
1159 <dd>
1160 <p>
1161 Usual 3-way file level merge for text files. Conflicted
1166 marker.
1167 </p>
1168 </dd>
1170 binary
1171 </dt>
1172 <dd>
1173 <p>
1174 Keep the version from your branch in the work tree, but
1175 leave the path in the conflicted state for the user to
1176 sort out.
1177 </p>
1178 </dd>
1180 union
1181 </dt>
1182 <dd>
1183 <p>
1184 Run 3-way file level merge for text files, but take
1185 lines from both versions, instead of leaving conflict
1186 markers. This tends to leave the added lines in the
1187 resulting file in random order and the user should
1188 verify the result. Do not use this if you do not
1189 understand the implications.
1190 </p>
1191 </dd>
1192 </dl></div>
1197 <div class="paragraph"><p>To define a custom merge driver <tt>filfre</tt>, add a section to your
1202 name = feel-free merge driver
1203 driver = filfre %O %A %B
1204 recursive = binary</tt></pre>
1205 </div></div>
1207 name.</p></div>
1208 <div class="paragraph"><p>The ‘merge.*.driver` variable’s value is used to construct a
1211 three tokens are replaced with the names of temporary files that
1212 hold the contents of these versions when the command line is
1213 built. Additionally, %L will be replaced with the conflict marker
1214 size (see below).</p></div>
1217 status if it managed to merge them cleanly, or non-zero if there
1218 were conflicts.</p></div>
1220 driver to use when the merge driver is called for an internal
1221 merge between common ancestors, when there are more than one.
1222 When left unspecified, the driver itself is used for both
1223 internal merge and the final merge.</p></div>
1226 the work tree file during a conflicted merge. Only setting to
1227 the value to a positive integer has any meaningful effect.</p></div>
1228 <div class="paragraph"><p>For example, this line in <tt>.gitattributes</tt> can be used to tell the merge
1229 machinery to leave much longer (instead of the usual 7-character-long)
1231 results in a conflict.</p></div>
1235 </div></div>
1236 <h3 id="_checking_whitespace_errors">Checking whitespace errors</h3><div style="clear:left"></div>
1238 <div class="paragraph"><p>The <tt>core.whitespace</tt> configuration variable allows you to define what
1241 control per path.</p></div>
1244 Set
1245 </dt>
1246 <dd>
1247 <p>
1248 Notice all types of potential whitespace errors known to git.
1250 configuration variable.
1251 </p>
1252 </dd>
1254 Unset
1255 </dt>
1256 <dd>
1257 <p>
1258 Do not notice anything as error.
1259 </p>
1260 </dd>
1262 Unspecified
1263 </dt>
1264 <dd>
1265 <p>
1267 decide what to notice as error.
1268 </p>
1269 </dd>
1271 String
1272 </dt>
1273 <dd>
1274 <p>
1275 Specify a comma separate list of common whitespace problems to
1277 variable.
1278 </p>
1279 </dd>
1280 </dl></div>
1283 <div class="paragraph"><p>Files and directories with the attribute <tt>export-ignore</tt> won’t be added to
1284 archive files.</p></div>
1286 <div class="paragraph"><p>If the attribute <tt>export-subst</tt> is set for a file then git will expand
1287 several placeholders when adding this file to an archive. The
1288 expansion depends on the availability of a commit ID, i.e., if
1290 tag then no replacement will be done. The placeholders are the same
1294 commit hash.</p></div>
1299 <h3 id="_viewing_files_in_gui_tools">Viewing files in GUI tools</h3><div style="clear:left"></div>
1301 <div class="paragraph"><p>The value of this attribute specifies the character encoding that should
1302 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
1303 display the contents of the relevant file. Note that due to performance
1305 manually enable per-file encodings in its options.</p></div>
1306 <div class="paragraph"><p>If this attribute is not set or has an invalid value, the value of the
1309 </div>
1312 <div class="paragraph"><p>You do not want any end-of-line conversions applied to, nor textual diffs
1313 produced for, any binary file you track. You would need to specify e.g.</p></div>
1317 </div></div>
1319 attribute macros, you can specify groups of attributes set or unset at
1324 </div></div>
1325 <div class="paragraph"><p>which is equivalent to the above. Note that the attribute macros can only
1328 </div>
1331 <div class="paragraph"><p>Custom attribute macros can be defined only in the <tt>.gitattributes</tt> file
1332 at the toplevel (i.e. not in any subdirectory). The built-in attribute
1337 </div></div>
1338 </div>
1344 <pre><tt>(in $GIT_DIR/info/attributes)
1346 a* foo !bar -baz
1348 (in .gitattributes)
1349 abc foo bar baz
1351 (in t/.gitattributes)
1352 ab* merge=filfre
1353 abc -foo -bar
1354 *.c frotz</tt></pre>
1355 </div></div>
1356 <div class="paragraph"><p>the attributes given to path <tt>t/abc</tt> are computed as follows:</p></div>
1358 <li>
1359 <p>
1361 directory as the path in question), git finds that the first
1364 are unset.
1365 </p>
1366 </li>
1367 <li>
1368 <p>
1370 directory), and finds that the first line matches, but
1374 </p>
1375 </li>
1376 <li>
1377 <p>
1379 is used to override the in-tree settings. The first line is
1382 </p>
1383 </li>
1384 </ol></div>
1385 <div class="paragraph"><p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p></div>
1388 <pre><tt>foo set to true
1389 bar unspecified
1390 baz set to false
1391 merge set to string value "filfre"
1392 frotz unspecified</tt></pre>
1393 </div></div>
1394 </div>
1398 </div>
1402 </div>
1403 </div>
1404 </body>
1405 </html>