| blob | e2dbf24754372b1704f669b40be2f684a676ba8f |
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 git-fast-import(1) Manual Page
407 </h1>
410 <p>git-fast-import -
411 Backend for fast Git data importers
412 </p>
413 </div>
414 </div>
418 </div>
422 Most end users want to use one of the existing frontend programs,
423 which parses a specific type of foreign source and feeds the contents
426 writes one or more packfiles directly into the current repository.
427 When EOF is received on standard input, fast import writes out
428 updated branch and tag refs, fully updating the current repository
429 with the newly imported data.</p></div>
430 <div class="paragraph"><p>The fast-import backend itself can import into an empty repository (one that
432 update an existing populated repository. Whether or not incremental
433 imports are supported from a particular foreign source depends on
434 the frontend program in use.</p></div>
435 </div>
441 </dt>
442 <dd>
443 <p>
444 Specify the type of dates the frontend will supply to
447 are supported, and their syntax.
448 </p>
449 </dd>
451 --force
452 </dt>
453 <dd>
454 <p>
455 Force updating modified existing branches, even if doing
456 so would cause commits to be lost (as the new commit does
457 not contain the old commit).
458 </p>
459 </dd>
462 </dt>
463 <dd>
464 <p>
465 Maximum size of each output packfile.
466 The default is unlimited.
467 </p>
468 </dd>
471 </dt>
472 <dd>
473 <p>
474 Maximum size of a blob that fast-import will attempt to
475 create a delta for, expressed in bytes. The default is 512m
476 (512 MiB). Some importers may wish to lower this on systems
477 with constrained memory.
478 </p>
479 </dd>
482 </dt>
483 <dd>
484 <p>
485 Maximum delta depth, for blob and tree deltification.
486 Default is 10.
487 </p>
488 </dd>
491 </dt>
492 <dd>
493 <p>
494 Maximum number of branches to maintain active at once.
496 </p>
497 </dd>
500 </dt>
501 <dd>
502 <p>
505 Frontends can use this file to validate imports after they
506 have been completed, or to save the marks table across
508 at checkpoint (or completion) the same path can also be
509 safely given to --import-marks.
510 </p>
511 </dd>
514 </dt>
515 <dd>
516 <p>
517 Before processing any input, load the marks specified in
519 must use the same format as produced by --export-marks.
520 Multiple options may be supplied to import more than one
521 set of marks. If a mark is defined to different values,
522 the last file wins.
523 </p>
524 </dd>
527 </dt>
528 <dd>
529 <p>
530 Like --import-marks but instead of erroring out, silently
531 skips the file if it does not exist.
532 </p>
533 </dd>
535 --relative-marks
536 </dt>
537 <dd>
538 <p>
539 After specifying --relative-marks= the paths specified
540 with --import-marks= and --export-marks= are relative
541 to an internal directory in the current repository.
542 In git-fast-import this means that the paths are relative
543 to the .git/info/fast-import directory. However, other
544 importers may use a different location.
545 </p>
546 </dd>
548 --no-relative-marks
549 </dt>
550 <dd>
551 <p>
552 Negates a previous --relative-marks. Allows for combining
553 relative and non-relative marks by interweaving
554 --(no-)-relative-marks= with the --(import|export)-marks=
555 options.
556 </p>
557 </dd>
560 </dt>
561 <dd>
562 <p>
563 Specify the file descriptor that will be written to
566 </p>
567 </dd>
570 </dt>
571 <dd>
572 <p>
573 After creating a packfile, print a line of data to
575 commit on each branch that was written to that packfile.
576 This information may be useful after importing projects
577 whose total object set exceeds the 4 GiB packfile limit,
578 as these commits can be used as edge points during calls
580 </p>
581 </dd>
583 --quiet
584 </dt>
585 <dd>
586 <p>
587 Disable all non-fatal output, making fast-import silent when it
588 is successful. This option disables the output shown by
589 --stats.
590 </p>
591 </dd>
593 --stats
594 </dt>
595 <dd>
596 <p>
597 Display some basic statistics about the objects fast-import has
598 created, the packfiles they were stored into, and the
599 memory used by fast-import during this run. Showing this output
600 is currently the default, but can be disabled with --quiet.
601 </p>
602 </dd>
603 </dl></div>
604 </div>
607 <div class="paragraph"><p>The design of fast-import allows it to import large projects in a minimum
608 amount of memory usage and processing time. Assuming the frontend
609 is able to keep up with fast-import and feed it a constant stream of data,
610 import times for projects holding 10+ years of history and containing
614 source just cannot extract revisions fast enough) or disk IO (fast-import
615 writes as fast as the disk will take the data). Imports will run
616 faster if the source data is stored on a different drive than the
617 destination Git repository (due to less IO contention).</p></div>
618 </div>
621 <div class="paragraph"><p>A typical frontend for fast-import tends to weigh in at approximately 200
622 lines of Perl/Python/Ruby code. Most developers have been able to
623 create working importers in just a couple of hours, even though it
624 is their first exposure to fast-import, and sometimes even to Git. This is
625 an ideal situation, given that most conversion tools are throw-away
626 (use once, and never look back).</p></div>
627 </div>
630 <div class="paragraph"><p>Like <em>git push</em> or <em>git fetch</em>, imports handled by fast-import are safe to
633 are never used by fast-import).</p></div>
634 <div class="paragraph"><p>fast-import does not lock the branch or tag refs it is actively importing.
635 After the import, during its ref update phase, fast-import tests each
636 existing branch ref to verify the update will be a fast-forward
637 update (the commit stored in the ref is contained in the new
638 history of the commit to be written). If the update is not a
639 fast-forward update, fast-import will skip updating that ref and instead
640 prints a warning message. fast-import will always attempt to update all
641 branch refs, and does not stop on the first failure.</p></div>
642 <div class="paragraph"><p>Branch updates can be forced with --force, but it’s recommended that
643 this only be used on an otherwise quiet repository. Using --force
644 is not necessary for an initial import into an empty repository.</p></div>
645 </div>
648 <div class="paragraph"><p>fast-import tracks a set of branches in memory. Any branch can be created
649 or modified at any point during the import process by sending a
651 program to process an unlimited number of branches simultaneously,
652 generating commits in the order they are available from the source
653 data. It also simplifies the frontend programs considerably.</p></div>
654 <div class="paragraph"><p>fast-import does not use or alter the current working directory, or any
655 file within it. (It does however update the current Git repository,
657 the working directory for its own purposes, such as extracting file
658 revisions from the foreign source. This ignorance of the working
659 directory also allows fast-import to run very quickly, as it does not
660 need to perform any costly file update operations when switching
661 between branches.</p></div>
662 </div>
666 the fast-import input format is text (ASCII) based. This text based
667 format simplifies development and debugging of frontend programs,
668 especially when a higher level language such as Perl, Python or
669 Ruby is being used.</p></div>
670 <div class="paragraph"><p>fast-import is very strict about its input. Where we say SP below we mean
672 Supplying additional whitespace characters will cause unexpected
673 results, such as branch names or file names with leading or trailing
674 spaces in their name, or early termination of fast-import when it encounters
675 unexpected input.</p></div>
680 that does not contain an LF and therefore may be used to include
681 any detailed debugging information that might be specific to the
682 frontend and useful when inspecting a fast-import data stream.</p></div>
685 the format it will use for this import by passing the format name
690 </dt>
691 <dd>
692 <p>
694 It is also fast-import’s default format, if --date-format was
695 not specified.
696 </p>
697 <div class="paragraph"><p>The time of the event is specified by <tt><time></tt> as the number of
699 written as an ASCII decimal integer.</p></div>
700 <div class="paragraph"><p>The local offset is specified by <tt><offutc></tt> as a positive or negative
701 offset from UTC. For example EST (which is 5 hours behind UTC)
702 would be expressed in <tt><tz></tt> by “-0500” while UTC is “+0000”.
704 advisement to help formatting routines display the timestamp.</p></div>
707 organizations have a CVS repository which has only ever been accessed
708 by users who are located in the same location and timezone. In this
709 case a reasonable offset from UTC could be assumed.</p></div>
711 variation in formatting will cause fast-import to reject the value.</p></div>
712 </dd>
715 </dt>
716 <dd>
717 <p>
718 This is the standard email format as described by RFC 2822.
719 </p>
720 <div class="paragraph"><p>An example value is “Tue Feb 6 11:22:18 2007 -0500”. The Git
721 parser is accurate, but a little on the lenient side. It is the
723 received from email.</p></div>
725 these cases Git will still be able to obtain the correct date from
726 the malformed string. There are also some types of malformed
727 strings which Git will parse wrong, and yet consider valid.
728 Seriously malformed strings will be rejected.</p></div>
729 <div class="paragraph"><p>Unlike the <tt>raw</tt> format above, the timezone/UTC offset information
730 contained in an RFC 2822 date string is used to adjust the date
731 value to UTC prior to storage. Therefore it is important that
732 this information be as accurate as possible.</p></div>
734 the frontend should let fast-import handle the parsing and conversion
735 (rather than attempting to do it itself) as the Git parser has
736 been well tested in the wild.</p></div>
737 <div class="paragraph"><p>Frontends should prefer the <tt>raw</tt> format if the source material
738 already uses UNIX-epoch format, can be coaxed to give dates in that
739 format, or its format is easily convertible to it, as there is no
740 ambiguity in parsing.</p></div>
741 </dd>
744 </dt>
745 <dd>
746 <p>
747 Always use the current time and timezone. The literal
749 </p>
751 is always copied into the identity string at the time it is being
752 created by fast-import. There is no way to specify a different time or
753 timezone.</p></div>
754 <div class="paragraph"><p>This particular format is supplied as it’s short to implement and
755 may be useful to a process that wants to create a new commit
756 right now, without needing to use a working directory or
758 <div class="paragraph"><p>If separate <tt>author</tt> and <tt>committer</tt> commands are used in a <tt>commit</tt>
759 the timestamps may not match, as the system clock will be polled
760 twice (once for each command). The only way to ensure that both
761 author and committer identity information has the same timestamp
764 </dd>
765 </dl></div>
768 and control the current import process. More detailed discussion
769 (with examples) of each command follows later.</p></div>
773 </dt>
774 <dd>
775 <p>
776 Creates a new branch or updates an existing branch by
777 creating a new commit and updating the branch to point at
778 the newly created commit.
779 </p>
780 </dd>
783 </dt>
784 <dd>
785 <p>
786 Creates an annotated tag object from an existing commit or
787 branch. Lightweight tags are not supported by this command,
788 as they are not recommended for recording meaningful points
789 in time.
790 </p>
791 </dd>
794 </dt>
795 <dd>
796 <p>
797 Reset an existing branch (or a new branch) to a specific
798 revision. This command must be used to change a branch to
799 a specific revision without making a commit on it.
800 </p>
801 </dd>
804 </dt>
805 <dd>
806 <p>
807 Convert raw file data into a blob, for future use in a
809 needed to perform an import.
810 </p>
811 </dd>
814 </dt>
815 <dd>
816 <p>
817 Forces fast-import to close the current packfile, generate its
818 unique SHA-1 checksum and index, and start a new packfile.
819 This command is optional and is not needed to perform
820 an import.
821 </p>
822 </dd>
825 </dt>
826 <dd>
827 <p>
828 Causes fast-import to echo the entire line to its own
829 standard output. This command is optional and is not needed
830 to perform an import.
831 </p>
832 </dd>
835 </dt>
836 <dd>
837 <p>
841 </p>
842 </dd>
845 </dt>
846 <dd>
847 <p>
848 Require that fast-import supports the specified feature, or
849 abort if it does not.
850 </p>
851 </dd>
854 </dt>
855 <dd>
856 <p>
857 Specify any of the options listed under OPTIONS that do not
858 change stream semantic to suit the frontend’s needs. This
859 command is optional and is not needed to perform an import.
860 </p>
861 </dd>
862 </dl></div>
865 change to the project.</p></div>
869 mark?
872 data
875 (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
876 LF?</tt></pre>
877 </div></div>
878 <div class="paragraph"><p>where <tt><ref></tt> is the name of the branch to make the commit on.
883 a Git refname, no quoting or escaping syntax is supported here.</p></div>
884 <div class="paragraph"><p>A <tt>mark</tt> command may optionally appear, requesting fast-import to save a
885 reference to the newly created commit for future use by the frontend
886 (see below for format). It is very common for frontends to mark
887 every commit they create, thereby allowing future branch creation
888 from any imported commit.</p></div>
889 <div class="paragraph"><p>The <tt>data</tt> command following <tt>committer</tt> must supply the commit
891 commit message use a 0 length data. Commit messages are free-form
892 and are not interpreted by Git. Currently they must be encoded in
894 <div class="paragraph"><p>Zero or more <tt>filemodify</tt>, <tt>filedelete</tt>, <tt>filecopy</tt>, <tt>filerename</tt>,
896 may be included to update the contents of the branch prior to
897 creating the commit. These commands may be supplied in any order.
899 all <tt>filemodify</tt>, <tt>filecopy</tt>, <tt>filerename</tt> and <tt>notemodify</tt> commands in
901 <div class="paragraph"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
903 <div class="paragraph"><p>An <tt>author</tt> command may optionally appear, if the author information
905 then fast-import will automatically use the committer’s information for
906 the author portion of the commit. See below for a description of
909 <div class="paragraph"><p>The <tt>committer</tt> command indicates who made this commit, and when
910 they made it.</p></div>
911 <div class="paragraph"><p>Here <tt><name></tt> is the person’s display name (for example
913 (“<a href="mailto:cm@example.com">cm@example.com</a>”). <tt>LT</tt> and <tt>GT</tt> are the literal less-than (\x3c)
914 and greater-than (\x3e) symbols. These are required to delimit
915 the email address from the other fields in the line. Note that
918 <div class="paragraph"><p>The time of the change is specified by <tt><when></tt> using the date format
921 their syntax.</p></div>
924 this branch from. This revision will be the first ancestor of the
925 new commit.</p></div>
926 <div class="paragraph"><p>Omitting the <tt>from</tt> command in the first commit of a new branch
927 will cause fast-import to create that commit with no ancestor. This
928 tends to be desired only for the initial commit of a project.
929 If the frontend creates all files from scratch when making a new
931 the commit with an empty tree.
933 as the current commit on that branch is automatically assumed to
934 be the first ancestor of the new commit.</p></div>
939 <li>
940 <p>
941 The name of an existing branch already in fast-import’s internal branch
943 expression.
944 </p>
945 </li>
946 <li>
947 <p>
949 </p>
950 <div class="paragraph"><p>The reason fast-import uses <tt>:</tt> to denote a mark reference is this character
955 <div class="paragraph"><p>Marks must be declared (via <tt>mark</tt>) before they can be used.</p></div>
956 </li>
957 <li>
958 <p>
960 </p>
961 </li>
962 <li>
963 <p>
964 Any valid Git SHA-1 expression that resolves to a commit. See
965 “SPECIFYING REVISIONS” in <a href="gitrevisions.html">gitrevisions(7)</a> for details.
966 </p>
967 </li>
968 </ul></div>
970 current branch value should be written as:</p></div>
974 </div></div>
975 <div class="paragraph"><p>The <tt>^0</tt> suffix is necessary as fast-import does not permit a branch to
976 start from itself, and the branch is created in memory before the
978 fast-import to resolve the commit through Git’s revision parsing library,
979 rather than its internal branch table, thereby loading in the
980 existing value of the branch.</p></div>
982 <div class="paragraph"><p>Includes one additional ancestor commit. If the <tt>from</tt> command is
984 the first ancestor of the current commit, and the branch will start
986 commit are permitted by fast-import, thereby establishing an n-way merge.
988 additional ancestors (forming a 16-way merge). For this reason
991 <div class="paragraph"><p>Here <tt><committish></tt> is any of the commit specification expressions
995 content of an existing file. This command has two different means
996 of specifying the content of the file.</p></div>
999 External data format
1000 </dt>
1001 <dd>
1002 <p>
1003 The data content for the file was already supplied by a prior
1005 </p>
1009 </div></div>
1010 <div class="paragraph"><p>Here usually <tt><dataref></tt> must be either a mark reference (<tt>:<idnum></tt>)
1015 </dd>
1017 Inline data format
1018 </dt>
1019 <dd>
1020 <p>
1021 The data content for the file has not been supplied yet.
1022 The frontend wants to supply it as part of this modify
1023 command.
1024 </p>
1028 data</tt></pre>
1029 </div></div>
1030 <div class="paragraph"><p>See below for a detailed description of the <tt>data</tt> command.</p></div>
1031 </dd>
1032 </dl></div>
1033 <div class="paragraph"><p>In both formats <tt><mode></tt> is the type of file entry, specified
1034 in octal. Git only supports the following modes:</p></div>
1036 <li>
1037 <p>
1039 of files in most projects use this mode. If in doubt, this is
1040 what you want.
1041 </p>
1042 </li>
1043 <li>
1044 <p>
1046 </p>
1047 </li>
1048 <li>
1049 <p>
1051 </p>
1052 </li>
1053 <li>
1054 <p>
1056 another repository. Git links can only be specified by SHA or through
1057 a commit mark. They are used to implement submodules.
1058 </p>
1059 </li>
1060 <li>
1061 <p>
1064 </p>
1065 </li>
1066 </ul></div>
1067 <div class="paragraph"><p>In both formats <tt><path></tt> is the complete path of the file to be added
1068 (if not already existing) or modified (if already existing).</p></div>
1069 <div class="paragraph"><p>A <tt><path></tt> string must use UNIX-style directory separators (forward
1072 <div class="paragraph"><p>If an <tt>LF</tt> or double quote must be encoded into <tt><path></tt> shell-style
1074 <div class="paragraph"><p>The value of <tt><path></tt> must be in canonical form. That is it must not:</p></div>
1076 <li>
1077 <p>
1079 </p>
1080 </li>
1081 <li>
1082 <p>
1084 </p>
1085 </li>
1086 <li>
1087 <p>
1089 </p>
1090 </li>
1091 <li>
1092 <p>
1095 </p>
1096 </li>
1097 </ul></div>
1098 <div class="paragraph"><p>The root of the tree can be represented by an empty string as <tt><path></tt>.</p></div>
1099 <div class="paragraph"><p>It is recommended that <tt><path></tt> always be encoded using UTF-8.</p></div>
1101 <div class="paragraph"><p>Included in a <tt>commit</tt> command to remove a file or recursively
1102 delete an entire directory from the branch. If the file or directory
1103 removal makes its parent directory empty, the parent directory will
1104 be automatically removed too. This cascades up the tree until the
1105 first non-empty directory or the root is reached.</p></div>
1109 </div></div>
1110 <div class="paragraph"><p>here <tt><path></tt> is the complete path of the file or subdirectory to
1111 be removed from the branch.
1115 location within the branch. The existing file or directory must
1116 exist. If the destination exists it will be completely replaced
1117 by the content copied from the source.</p></div>
1121 </div></div>
1122 <div class="paragraph"><p>here the first <tt><path></tt> is the source location and the second
1125 that contains SP the path must be quoted.</p></div>
1126 <div class="paragraph"><p>A <tt>filecopy</tt> command takes effect immediately. Once the source
1127 location has been copied to the destination any future commands
1128 applied to the source location will not impact the destination of
1129 the copy.</p></div>
1132 within the branch. The existing file or directory must exist. If
1133 the destination exists it will be replaced by the source directory.</p></div>
1137 </div></div>
1138 <div class="paragraph"><p>here the first <tt><path></tt> is the source location and the second
1141 that contains SP the path must be quoted.</p></div>
1142 <div class="paragraph"><p>A <tt>filerename</tt> command takes effect immediately. Once the source
1143 location has been renamed to the destination any future commands
1144 applied to the source location will create new files there and not
1145 impact the destination of the rename.</p></div>
1146 <div class="paragraph"><p>Note that a <tt>filerename</tt> is the same as a <tt>filecopy</tt> followed by a
1149 that it is never worth trying to convert a delete/add pair in
1151 command is provided just to simplify frontends that already have
1152 rename information and don’t want bother with decomposing it into a
1155 <div class="paragraph"><p>Included in a <tt>commit</tt> command to remove all files (and also all
1156 directories) from the branch. This command resets the internal
1157 branch structure to have no files in it, allowing the frontend
1158 to subsequently add all interesting files from scratch.</p></div>
1162 </div></div>
1164 (or does not care to know) what files are currently on the branch,
1166 update the content.</p></div>
1167 <div class="paragraph"><p>Issuing a <tt>filedeleteall</tt> followed by the needed <tt>filemodify</tt>
1168 commands to set the correct content will produce the same results
1171 more memory per active branch (less than 1 MiB for even most large
1172 projects); so frontends that can easily obtain only the affected
1173 paths for a commit are encouraged to do so.</p></div>
1175 <div class="paragraph"><p>Included in a <tt>commit</tt> command to add a new note (annotating a given
1176 commit) or change the content of an existing note. This command has
1177 two different means of specifying the content of the note.</p></div>
1180 External data format
1181 </dt>
1182 <dd>
1183 <p>
1184 The data content for the note was already supplied by a prior
1186 commit that is to be annotated.
1187 </p>
1191 </div></div>
1192 <div class="paragraph"><p>Here <tt><dataref></tt> can be either a mark reference (<tt>:<idnum></tt>)
1194 existing Git blob object.</p></div>
1195 </dd>
1197 Inline data format
1198 </dt>
1199 <dd>
1200 <p>
1201 The data content for the note has not been supplied yet.
1202 The frontend wants to supply it as part of this modify
1203 command.
1204 </p>
1208 data</tt></pre>
1209 </div></div>
1210 <div class="paragraph"><p>See below for a detailed description of the <tt>data</tt> command.</p></div>
1211 </dd>
1212 </dl></div>
1213 <div class="paragraph"><p>In both formats <tt><committish></tt> is any of the commit specification
1216 <div class="paragraph"><p>Arranges for fast-import to save a reference to the current object, allowing
1217 the frontend to recall this object at a future point in time, without
1218 knowing its SHA-1. Here the current object is the object creation
1224 </div></div>
1225 <div class="paragraph"><p>where <tt><idnum></tt> is the number assigned by the frontend to this mark.
1227 The value 0 is reserved and cannot be used as
1240 data</tt></pre>
1241 </div></div>
1242 <div class="paragraph"><p>where <tt><name></tt> is the name of the tag to create.</p></div>
1243 <div class="paragraph"><p>Tag names are automatically prefixed with <tt>refs/tags/</tt> when stored
1247 <div class="paragraph"><p>The value of <tt><name></tt> must be a valid refname in Git and therefore
1249 no quoting or escaping syntax is supported here.</p></div>
1250 <div class="paragraph"><p>The <tt>from</tt> command is the same as in the <tt>commit</tt> command; see
1251 above for details.</p></div>
1252 <div class="paragraph"><p>The <tt>tagger</tt> command uses the same format as <tt>committer</tt> within
1254 <div class="paragraph"><p>The <tt>data</tt> command following <tt>tagger</tt> must supply the annotated tag
1256 tag message use a 0 length data. Tag messages are free-form and are
1257 not interpreted by Git. Currently they must be encoded in UTF-8,
1258 as fast-import does not permit other encodings to be specified.</p></div>
1260 supported. Trying to include your own PGP/GPG signature is not
1261 recommended, as the frontend does not (easily) have access to the
1262 complete set of bytes which normally goes into such a signature.
1263 If signing is required, create lightweight tags from within fast-import with
1268 a specific revision. The reset command allows a frontend to issue
1270 branch from an existing commit without creating a new commit.</p></div>
1275 LF?</tt></pre>
1276 </div></div>
1277 <div class="paragraph"><p>For a detailed description of <tt><ref></tt> and <tt><committish></tt> see above
1279 <div class="paragraph"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
1281 (non-annotated) tags. For example:</p></div>
1288 </div></div>
1289 </div></div>
1294 is not connected to any commit; this connection must be formed in
1296 assigned mark.</p></div>
1299 <pre><tt> 'blob' LF
1300 mark?
1301 data</tt></pre>
1302 </div></div>
1304 to generate the Git SHA-1 for the blob on their own, and feed that
1306 however, as marks are inexpensive to store and easy to use.</p></div>
1309 annotated tag messages) to fast-import. Data can be supplied using an exact
1310 byte count or delimited with a terminating line. Real frontends
1311 intended for production-quality conversions should always use the
1312 exact byte count format, as it is more robust and performs better.
1313 The delimited format is intended primarily for testing fast-import.</p></div>
1314 <div class="paragraph"><p>Comment lines appearing within the <tt><raw></tt> part of <tt>data</tt> commands
1315 are always taken to be part of the body of the data and are therefore
1316 never ignored by fast-import. This makes it safe to import any
1320 Exact byte count format
1321 </dt>
1322 <dd>
1323 <p>
1324 The frontend must specify the number of bytes of data.
1325 </p>
1330 </div></div>
1331 <div class="paragraph"><p>where <tt><count></tt> is the exact number of bytes appearing within
1335 <div class="paragraph"><p>The <tt>LF</tt> after <tt><raw></tt> is optional (it used to be required) but
1336 recommended. Always including it makes debugging a fast-import
1337 stream easier as the next command always starts in column 0
1339 </dd>
1341 Delimited format
1342 </dt>
1343 <dd>
1344 <p>
1345 A delimiter string is used to mark the end of the data.
1346 fast-import will compute the length by searching for the delimiter.
1347 This format is primarily useful for testing and is not
1348 recommended for real data.
1349 </p>
1355 LF?</tt></pre>
1356 </div></div>
1357 <div class="paragraph"><p>where <tt><delim></tt> is the chosen delimiter string. The string <tt><delim></tt>
1361 the limitations of the delimited format, it is impossible to supply
1362 a data chunk which does not have an LF as its last byte.</p></div>
1363 <div class="paragraph"><p>The <tt>LF</tt> after <tt><delim> LF</tt> is optional (it used to be required).</p></div>
1364 </dd>
1365 </dl></div>
1367 <div class="paragraph"><p>Forces fast-import to close the current packfile, start a new one, and to
1368 save out all current branch refs, tags and marks.</p></div>
1371 <pre><tt> 'checkpoint' LF
1372 LF?</tt></pre>
1373 </div></div>
1374 <div class="paragraph"><p>Note that fast-import automatically switches packfiles when the current
1375 packfile reaches --max-pack-size, or 4 GiB, whichever limit is
1376 smaller. During an automatic packfile switch fast-import does not update
1377 the branch refs, tags or marks.</p></div>
1378 <div class="paragraph"><p>As a <tt>checkpoint</tt> can require a significant amount of CPU time and
1379 disk IO (to compute the overall pack SHA-1 checksum, generate the
1380 corresponding index file, and update the refs) it can easily take
1383 and long running imports, or when they need to allow another Git
1384 process access to a branch. However given that a 30 GiB Subversion
1385 repository can be loaded into Git through fast-import in about 3 hours,
1386 explicit checkpointing may not be necessary.</p></div>
1387 <div class="paragraph"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
1389 <div class="paragraph"><p>Causes fast-import to print the entire <tt>progress</tt> line unmodified to
1390 its standard output channel (file descriptor 1) when the command is
1391 processed from the input stream. The command otherwise has no impact
1396 LF?</tt></pre>
1397 </div></div>
1398 <div class="paragraph"><p>The <tt><any></tt> part of the command may contain any sequence of bytes
1400 Callers may wish to process the output through a tool such as sed to
1401 remove the leading part of the line, for example:</p></div>
1407 </div></div>
1408 </div></div>
1409 <div class="paragraph"><p>Placing a <tt>progress</tt> command immediately after a <tt>checkpoint</tt> will
1411 can safely access the refs that fast-import updated.</p></div>
1415 has no impact on the current import; its main purpose is to
1416 retrieve blobs that may be in fast-import’s memory but not
1417 accessible from the target repository.</p></div>
1421 </div></div>
1422 <div class="paragraph"><p>The <tt><dataref></tt> can be either a mark reference (<tt>:<idnum></tt>)
1424 ready to be written.</p></div>
1425 <div class="paragraph"><p>Output uses the same format as <tt>git cat-file --batch</tt>:</p></div>
1432 </div></div>
1433 </div></div>
1439 it does not.</p></div>
1443 </div></div>
1444 <div class="paragraph"><p>The <feature> part of the command may be any one of the following:</p></div>
1447 date-format
1448 </dt>
1450 export-marks
1451 </dt>
1453 relative-marks
1454 </dt>
1456 no-relative-marks
1457 </dt>
1459 force
1460 </dt>
1461 <dd>
1462 <p>
1463 Act as though the corresponding command-line option with
1465 (see OPTIONS, above).
1466 </p>
1467 </dd>
1469 import-marks
1470 </dt>
1471 <dd>
1472 <p>
1473 Like --import-marks except in two respects: first, only one
1474 "feature import-marks" command is allowed per stream;
1475 second, an --import-marks= command-line option overrides
1476 any "feature import-marks" command in the stream.
1477 </p>
1478 </dd>
1480 cat-blob
1481 </dt>
1482 <dd>
1483 <p>
1484 Ignored. Versions of fast-import not supporting the
1485 "cat-blob" command will exit with a message indicating so.
1486 This lets the import error out early with a clear message,
1487 rather than wasting time on the early part of an import
1488 before the unsupported command is detected.
1489 </p>
1490 </dd>
1492 notes
1493 </dt>
1494 <dd>
1495 <p>
1498 Versions of fast-import not supporting notes will exit
1499 with a message indicating so.
1500 </p>
1501 </dd>
1502 </dl></div>
1505 way that suits the frontend’s needs.
1506 Note that options specified by the frontend are overridden by any
1507 options the user may specify to git fast-import itself.</p></div>
1511 </div></div>
1512 <div class="paragraph"><p>The <tt><option></tt> part of the command may contain any of the options
1513 listed in the OPTIONS section that do not change import semantics,
1515 <div class="paragraph"><p>Option commands must be the first commands on the input (not counting
1516 feature commands), to give an option command after any non-option
1517 command is an error.</p></div>
1518 <div class="paragraph"><p>The following commandline options change import semantics and may therefore
1519 not be passed as option:</p></div>
1521 <li>
1522 <p>
1523 date-format
1524 </p>
1525 </li>
1526 <li>
1527 <p>
1528 import-marks
1529 </p>
1530 </li>
1531 <li>
1532 <p>
1533 export-marks
1534 </p>
1535 </li>
1536 <li>
1537 <p>
1538 cat-blob-fd
1539 </p>
1540 </li>
1541 <li>
1542 <p>
1543 force
1544 </p>
1545 </li>
1546 </ul></div>
1547 </div>
1551 non-zero exit status and create a crash report in the top level of
1552 the Git repository it was importing into. Crash reports contain
1553 a snapshot of the internal fast-import state as well as the most
1554 recent commands that lead up to the crash.</p></div>
1556 progress commands) are shown in the command history within the crash
1557 report, but raw file data and commit messages are excluded from the
1558 crash report. This exclusion saves space within the report file
1559 and reduces the amount of buffering that fast-import must perform
1560 during execution.</p></div>
1562 packfile and export the marks table. This allows the frontend
1563 developer to inspect the repository state and resume the import from
1564 the point where it crashed. The modified branches and tags are not
1565 updated during a crash, as the import did not complete successfully.
1566 Branch and tag information can be found in the crash report and
1567 must be applied manually if the update is needed.</p></div>
1574 # my very first test commit
1575 commit refs/heads/master
1577 # who is that guy anyway?
1578 data <<EOF
1579 this is my commit
1580 EOF
1581 M 644 inline .gitignore
1582 data <<EOF
1583 .gitignore
1584 EOF
1585 M 777 inline bob
1586 END_OF_INPUT</tt></pre>
1587 </div></div>
1591 fatal: Corrupt mode: M 777 inline bob
1592 fast-import: dumping crash report to .git/fast_import_crash_8434</tt></pre>
1593 </div></div>
1596 <pre><tt>$ cat .git/fast_import_crash_8434
1597 fast-import crash report:
1598 fast-import process: 8434
1599 parent process : 1391
1601 </div></div>
1605 </div></div>
1608 <pre><tt>Most Recent Commands Before Crash
1609 ---------------------------------
1610 # my very first test commit
1611 commit refs/heads/master
1613 # who is that guy anyway?
1614 data <<EOF
1615 M 644 inline .gitignore
1616 data <<EOF
1618 </div></div>
1621 <pre><tt>Active Branch LRU
1622 -----------------
1624 </div></div>
1627 <pre><tt>pos clock name
1628 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1630 </div></div>
1633 <pre><tt>Inactive Branches
1634 -----------------
1635 refs/heads/master:
1636 status : active loaded dirty
1637 tip commit : 0000000000000000000000000000000000000000
1638 old tree : 0000000000000000000000000000000000000000
1639 cur tree : 0000000000000000000000000000000000000000
1640 commit clock: 0
1641 last pack :</tt></pre>
1642 </div></div>
1645 <pre><tt>-------------------
1646 END OF CRASH REPORT</tt></pre>
1647 </div></div>
1648 </div></div>
1649 </div>
1653 users of fast-import, and are offered here as suggestions.</p></div>
1657 line. fast-import will dump a file which lists every mark and the Git
1658 object SHA-1 that corresponds to it. If the frontend can tie
1659 the marks back to the source repository, it is easy to verify the
1660 accuracy and completeness of the import by comparing each Git
1661 commit to the corresponding source revision.</p></div>
1663 quite simple, as the fast-import mark can also be the Perforce changeset
1664 number or the Subversion revision number.</p></div>
1665 <h3 id="_freely_skip_around_branches">Freely Skip Around Branches</h3><div style="clear:left"></div>
1666 <div class="paragraph"><p>Don’t bother trying to optimize the frontend to stick to one branch
1667 at a time during an import. Although doing so might be slightly
1668 faster for fast-import, it tends to increase the complexity of the frontend
1669 code considerably.</p></div>
1670 <div class="paragraph"><p>The branch LRU builtin to fast-import tends to behave very well, and the
1671 cost of activating an inactive branch is so low that bouncing around
1672 between branches has virtually no impact on import performance.</p></div>
1675 name(s) and modify the new name(s) during the corresponding commit.
1676 Git performs rename detection after-the-fact, rather than explicitly
1677 during a commit.</p></div>
1680 files which are not from the same commit/changeset. Or to create
1681 tags which are a subset of the files available in the repository.</p></div>
1685 outside of your normal branch space to the base commit for the tag,
1686 then commit one or more file fixup commits, and finally tag the
1687 dummy branch.</p></div>
1688 <div class="paragraph"><p>For example since all normal branches are stored under <tt>refs/heads/</tt>
1690 the fixup branch used by the importer to have namespace conflicts
1694 commit(s) which are supplying file revisions to the fixup branch.
1696 through the real commit history and properly annotate the source
1697 files.</p></div>
1698 <div class="paragraph"><p>After fast-import terminates the frontend will need to do <tt>rm .git/TAG_FIXUP</tt>
1699 to remove the dummy branch.</p></div>
1701 <div class="paragraph"><p>As soon as fast-import completes the Git repository is completely valid
1702 and ready for use. Typically this takes only a very short time,
1705 locality and access performance. It can also take hours on extremely
1706 large projects (especially if -f and a large --window parameter is
1707 used). Since repacking is safe to run alongside readers and writers,
1708 run the repack in the background and let it finish when it finishes.
1709 There is no reason to wait to explore your new Git project!</p></div>
1710 <div class="paragraph"><p>If you choose to wait for the repack, don’t try to run benchmarks
1711 or performance tests until repacking is completed. fast-import outputs
1712 suboptimal packfiles that are simply never seen in real use
1713 situations.</p></div>
1714 <h3 id="_repacking_historical_data">Repacking Historical Data</h3><div style="clear:left"></div>
1716 last year), consider expending some extra CPU time and supplying
1718 This will take longer, but will also produce a smaller packfile.
1719 You only need to expend the effort once, and everyone using your
1720 project will benefit from the smaller repository.</p></div>
1721 <h3 id="_include_some_progress_messages">Include Some Progress Messages</h3><div style="clear:left"></div>
1722 <div class="paragraph"><p>Every once in a while have your frontend emit a <tt>progress</tt> message
1723 to fast-import. The contents of the messages are entirely free-form,
1724 so one suggestion would be to output the current month and year
1725 each time the current commit date moves into the next month.
1726 Your users will feel better knowing how much of the data stream
1727 has been processed.</p></div>
1728 </div>
1731 <div class="paragraph"><p>When packing a blob fast-import always attempts to deltify against the last
1732 blob written. Unless specifically arranged for by the frontend,
1733 this will probably not be a prior version of the same file, so the
1734 generated delta will not be the smallest possible. The resulting
1735 packfile will be compressed, but will not be optimal.</p></div>
1737 single file (for example reading an RCS/CVS ,v file) can choose
1738 to supply all revisions of that file as a sequence of consecutive
1740 revisions against each other, saving space in the final packfile.
1741 Marks can be used to later identify individual file revisions during
1743 <div class="paragraph"><p>The packfile(s) created by fast-import do not encourage good disk access
1744 patterns. This is caused by fast-import writing the data in the order
1745 it is received on standard input, while Git typically organizes
1746 data within packfiles to make the most recent (current tip) data
1747 appear before historical data. Git also clusters commits together,
1748 speeding up revision traversal through better cache locality.</p></div>
1751 Git to reorganize the packfiles for faster data access. If blob
1753 to force recomputation of all deltas can significantly reduce the
1755 </div>
1758 <div class="paragraph"><p>There are a number of factors which affect how much memory fast-import
1759 requires to perform an import. Like critical sections of core
1760 Git, fast-import uses its own memory allocators to amortize any overheads
1761 associated with malloc. In practice fast-import tends to amortize any
1764 <div class="paragraph"><p>fast-import maintains an in-memory structure for every object written in
1767 pointer sizes). Objects in the table are not deallocated until
1771 (the unique SHA-1). This storage configuration allows fast-import to reuse
1772 an existing or already written object and avoid writing duplicates
1773 to the output packfile. Duplicate blobs are surprisingly common
1774 in an import, typically due to branch merges in the source.</p></div>
1777 bytes, depending on pointer size) per mark. Although the array
1778 is sparse, frontends are still strongly encouraged to use marks
1779 between 1 and n, where n is the total number of marks required for
1780 this import.</p></div>
1783 of the two classes is significantly different.</p></div>
1786 the branch name (typically under 200 bytes), per branch. fast-import will
1788 of memory.</p></div>
1790 also contain copies of every tree that has been recently modified on
1792 branch became active, its contents will not be loaded into memory,
1794 became active, then its contents will be loaded in memory.</p></div>
1796 branch, their in-memory storage size can grow to a considerable size
1797 (see below).</p></div>
1798 <div class="paragraph"><p>fast-import automatically moves active branches to inactive status based on
1799 a simple least-recently-used algorithm. The LRU chain is updated on
1801 increased or decreased on the command line with --active-branches=.</p></div>
1805 The cost of a tree is virtually 0, as its overhead amortizes out
1806 over the individual file entries.</p></div>
1808 <div class="paragraph"><p>Files (and pointers to subtrees) within active trees require 52 or 64
1810 tree names are pooled in a common string table, allowing the filename
1812 overhead) no matter how many times it occurs within the project.</p></div>
1814 and lazy loading of subtrees, allows fast-import to efficiently import
1817 </div>
1820 <div class="paragraph"><p>Sending <strong>SIGUSR1</strong> to the <em>git fast-import</em> process ends the current
1822 operator can use this facility to peek at the objects and refs from an
1823 import in progress, at the cost of some added running time and worse
1824 compression.</p></div>
1825 </div>
1828 <div class="paragraph"><p>Written by Shawn O. Pearce <<a href="mailto:spearce@spearce.org">spearce@spearce.org</a>>.</p></div>
1829 </div>
1832 <div class="paragraph"><p>Documentation by Shawn O. Pearce <<a href="mailto:spearce@spearce.org">spearce@spearce.org</a>>.</p></div>
1833 </div>
1837 </div>
1841 </div>
1842 </div>
1843 </body>
1844 </html>