| blob | 491f2eb1e81fb0d1e08d300119ae58c7e31cda27 |
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 git-fast-import(1) Manual Page
313 </h1>
316 <p>git-fast-import -
317 Backend for fast Git data importers
318 </p>
319 </div>
320 </div>
324 </div>
328 Most end users want to use one of the existing frontend programs,
329 which parses a specific type of foreign source and feeds the contents
332 writes one or more packfiles directly into the current repository.
333 When EOF is received on standard input, fast import writes out
334 updated branch and tag refs, fully updating the current repository
335 with the newly imported data.</p></div>
336 <div class="para"><p>The fast-import backend itself can import into an empty repository (one that
338 update an existing populated repository. Whether or not incremental
339 imports are supported from a particular foreign source depends on
340 the frontend program in use.</p></div>
341 </div>
345 <dt>
347 </dt>
348 <dd>
349 <p>
350 Specify the type of dates the frontend will supply to
353 are supported, and their syntax.
354 </p>
355 </dd>
356 <dt>
357 --force
358 </dt>
359 <dd>
360 <p>
361 Force updating modified existing branches, even if doing
362 so would cause commits to be lost (as the new commit does
363 not contain the old commit).
364 </p>
365 </dd>
366 <dt>
368 </dt>
369 <dd>
370 <p>
371 Maximum size of each output packfile, expressed in MiB.
373 packfile size (due to file format limitations). Some
374 importers may wish to lower this, such as to ensure the
375 resulting packfiles fit on CDs.
376 </p>
377 </dd>
378 <dt>
380 </dt>
381 <dd>
382 <p>
383 Maximum delta depth, for blob and tree deltification.
384 Default is 10.
385 </p>
386 </dd>
387 <dt>
389 </dt>
390 <dd>
391 <p>
392 Maximum number of branches to maintain active at once.
394 </p>
395 </dd>
396 <dt>
398 </dt>
399 <dd>
400 <p>
403 Frontends can use this file to validate imports after they
404 have been completed, or to save the marks table across
406 at checkpoint (or completion) the same path can also be
407 safely given to --import-marks.
408 </p>
409 </dd>
410 <dt>
412 </dt>
413 <dd>
414 <p>
415 Before processing any input, load the marks specified in
417 must use the same format as produced by --export-marks.
418 Multiple options may be supplied to import more than one
419 set of marks. If a mark is defined to different values,
420 the last file wins.
421 </p>
422 </dd>
423 <dt>
425 </dt>
426 <dd>
427 <p>
428 After creating a packfile, print a line of data to
430 commit on each branch that was written to that packfile.
431 This information may be useful after importing projects
432 whose total object set exceeds the 4 GiB packfile limit,
433 as these commits can be used as edge points during calls
435 </p>
436 </dd>
437 <dt>
438 --quiet
439 </dt>
440 <dd>
441 <p>
442 Disable all non-fatal output, making fast-import silent when it
443 is successful. This option disables the output shown by
444 --stats.
445 </p>
446 </dd>
447 <dt>
448 --stats
449 </dt>
450 <dd>
451 <p>
452 Display some basic statistics about the objects fast-import has
453 created, the packfiles they were stored into, and the
454 memory used by fast-import during this run. Showing this output
455 is currently the default, but can be disabled with --quiet.
456 </p>
457 </dd>
458 </dl></div>
459 </div>
463 amount of memory usage and processing time. Assuming the frontend
464 is able to keep up with fast-import and feed it a constant stream of data,
465 import times for projects holding 10+ years of history and containing
469 source just cannot extract revisions fast enough) or disk IO (fast-import
470 writes as fast as the disk will take the data). Imports will run
471 faster if the source data is stored on a different drive than the
472 destination Git repository (due to less IO contention).</p></div>
473 </div>
477 lines of Perl/Python/Ruby code. Most developers have been able to
478 create working importers in just a couple of hours, even though it
479 is their first exposure to fast-import, and sometimes even to Git. This is
480 an ideal situation, given that most conversion tools are throw-away
481 (use once, and never look back).</p></div>
482 </div>
485 <div class="para"><p>Like <em>git-push</em> or <em>git-fetch</em>, imports handled by fast-import are safe to
488 are never used by fast-import).</p></div>
490 After the import, during its ref update phase, fast-import tests each
491 existing branch ref to verify the update will be a fast-forward
492 update (the commit stored in the ref is contained in the new
493 history of the commit to be written). If the update is not a
494 fast-forward update, fast-import will skip updating that ref and instead
495 prints a warning message. fast-import will always attempt to update all
496 branch refs, and does not stop on the first failure.</p></div>
498 this only be used on an otherwise quiet repository. Using --force
499 is not necessary for an initial import into an empty repository.</p></div>
500 </div>
504 or modified at any point during the import process by sending a
506 program to process an unlimited number of branches simultaneously,
507 generating commits in the order they are available from the source
508 data. It also simplifies the frontend programs considerably.</p></div>
510 file within it. (It does however update the current Git repository,
512 the working directory for its own purposes, such as extracting file
513 revisions from the foreign source. This ignorance of the working
514 directory also allows fast-import to run very quickly, as it does not
515 need to perform any costly file update operations when switching
516 between branches.</p></div>
517 </div>
521 the fast-import input format is text (ASCII) based. This text based
522 format simplifies development and debugging of frontend programs,
523 especially when a higher level language such as Perl, Python or
524 Ruby is being used.</p></div>
527 Supplying additional whitespace characters will cause unexpected
528 results, such as branch names or file names with leading or trailing
529 spaces in their name, or early termination of fast-import when it encounters
530 unexpected input.</p></div>
535 that does not contain an LF and therefore may be used to include
536 any detailed debugging information that might be specific to the
537 frontend and useful when inspecting a fast-import data stream.</p></div>
540 the format it will use for this import by passing the format name
543 <dt>
545 </dt>
546 <dd>
547 <p>
549 It is also fast-import's default format, if --date-format was
550 not specified.
551 </p>
552 <div class="para"><p>The time of the event is specified by <tt><time></tt> as the number of
554 written as an ASCII decimal integer.</p></div>
555 <div class="para"><p>The local offset is specified by <tt><offutc></tt> as a positive or negative
556 offset from UTC. For example EST (which is 5 hours behind UTC)
557 would be expressed in <tt><tz></tt> by “-0500” while UTC is “+0000”.
559 advisement to help formatting routines display the timestamp.</p></div>
562 organizations have a CVS repository which has only ever been accessed
563 by users who are located in the same location and timezone. In this
564 case a reasonable offset from UTC could be assumed.</p></div>
566 variation in formatting will cause fast-import to reject the value.</p></div>
567 </dd>
568 <dt>
570 </dt>
571 <dd>
572 <p>
573 This is the standard email format as described by RFC 2822.
574 </p>
576 parser is accurate, but a little on the lenient side. It is the
578 received from email.</p></div>
580 these cases Git will still be able to obtain the correct date from
581 the malformed string. There are also some types of malformed
582 strings which Git will parse wrong, and yet consider valid.
583 Seriously malformed strings will be rejected.</p></div>
585 contained in an RFC 2822 date string is used to adjust the date
586 value to UTC prior to storage. Therefore it is important that
587 this information be as accurate as possible.</p></div>
589 the frontend should let fast-import handle the parsing and conversion
590 (rather than attempting to do it itself) as the Git parser has
591 been well tested in the wild.</p></div>
593 already uses UNIX-epoch format, can be coaxed to give dates in that
594 format, or its format is easily convertible to it, as there is no
595 ambiguity in parsing.</p></div>
596 </dd>
597 <dt>
599 </dt>
600 <dd>
601 <p>
602 Always use the current time and timezone. The literal
604 </p>
606 is always copied into the identity string at the time it is being
607 created by fast-import. There is no way to specify a different time or
608 timezone.</p></div>
610 may be useful to a process that wants to create a new commit
611 right now, without needing to use a working directory or
613 <div class="para"><p>If separate <tt>author</tt> and <tt>committer</tt> commands are used in a <tt>commit</tt>
614 the timestamps may not match, as the system clock will be polled
615 twice (once for each command). The only way to ensure that both
616 author and committer identity information has the same timestamp
619 </dd>
620 </dl></div>
623 and control the current import process. More detailed discussion
624 (with examples) of each command follows later.</p></div>
626 <dt>
628 </dt>
629 <dd>
630 <p>
631 Creates a new branch or updates an existing branch by
632 creating a new commit and updating the branch to point at
633 the newly created commit.
634 </p>
635 </dd>
636 <dt>
638 </dt>
639 <dd>
640 <p>
641 Creates an annotated tag object from an existing commit or
642 branch. Lightweight tags are not supported by this command,
643 as they are not recommended for recording meaningful points
644 in time.
645 </p>
646 </dd>
647 <dt>
649 </dt>
650 <dd>
651 <p>
652 Reset an existing branch (or a new branch) to a specific
653 revision. This command must be used to change a branch to
654 a specific revision without making a commit on it.
655 </p>
656 </dd>
657 <dt>
659 </dt>
660 <dd>
661 <p>
662 Convert raw file data into a blob, for future use in a
664 needed to perform an import.
665 </p>
666 </dd>
667 <dt>
669 </dt>
670 <dd>
671 <p>
672 Forces fast-import to close the current packfile, generate its
673 unique SHA-1 checksum and index, and start a new packfile.
674 This command is optional and is not needed to perform
675 an import.
676 </p>
677 </dd>
678 <dt>
680 </dt>
681 <dd>
682 <p>
683 Causes fast-import to echo the entire line to its own
684 standard output. This command is optional and is not needed
685 to perform an import.
686 </p>
687 </dd>
688 </dl></div>
691 change to the project.</p></div>
695 mark?
698 data
701 (filemodify | filedelete | filecopy | filerename | filedeleteall)*
702 LF?</tt></pre>
703 </div></div>
704 <div class="para"><p>where <tt><ref></tt> is the name of the branch to make the commit on.
709 a Git refname, no quoting or escaping syntax is supported here.</p></div>
710 <div class="para"><p>A <tt>mark</tt> command may optionally appear, requesting fast-import to save a
711 reference to the newly created commit for future use by the frontend
712 (see below for format). It is very common for frontends to mark
713 every commit they create, thereby allowing future branch creation
714 from any imported commit.</p></div>
715 <div class="para"><p>The <tt>data</tt> command following <tt>committer</tt> must supply the commit
717 commit message use a 0 length data. Commit messages are free-form
718 and are not interpreted by Git. Currently they must be encoded in
720 <div class="para"><p>Zero or more <tt>filemodify</tt>, <tt>filedelete</tt>, <tt>filecopy</tt>, <tt>filerename</tt>
722 may be included to update the contents of the branch prior to
723 creating the commit. These commands may be supplied in any order.
727 wipes the branch clean (see below).</p></div>
728 <div class="para"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
730 <div class="para"><p>An <tt>author</tt> command may optionally appear, if the author information
732 then fast-import will automatically use the committer's information for
733 the author portion of the commit. See below for a description of
737 they made it.</p></div>
741 and greater-than (\x3e) symbols. These are required to delimit
742 the email address from the other fields in the line. Note that
745 <div class="para"><p>The time of the change is specified by <tt><when></tt> using the date format
748 their syntax.</p></div>
751 this branch from. This revision will be the first ancestor of the
752 new commit.</p></div>
754 will cause fast-import to create that commit with no ancestor. This
755 tends to be desired only for the initial commit of a project.
756 If the frontend creates all files from scratch when making a new
758 the commit with an empty tree.
760 as the current commit on that branch is automatically assumed to
761 be the first ancestor of the new commit.</p></div>
766 <li>
767 <p>
768 The name of an existing branch already in fast-import's internal branch
769 table. If fast-import doesn't know the name, its treated as a SHA-1
770 expression.
771 </p>
772 </li>
773 <li>
774 <p>
776 </p>
777 <div class="para"><p>The reason fast-import uses <tt>:</tt> to denote a mark reference is this character
782 <div class="para"><p>Marks must be declared (via <tt>mark</tt>) before they can be used.</p></div>
783 </li>
784 <li>
785 <p>
787 </p>
788 </li>
789 <li>
790 <p>
791 Any valid Git SHA-1 expression that resolves to a commit. See
792 “SPECIFYING REVISIONS” in <a href="git-rev-parse.html">git-rev-parse(1)</a> for details.
793 </p>
794 </li>
795 </ul></div>
797 current branch value should be written as:</p></div>
801 </div></div>
802 <div class="para"><p>The <tt>^0</tt> suffix is necessary as fast-import does not permit a branch to
803 start from itself, and the branch is created in memory before the
805 fast-import to resolve the commit through Git's revision parsing library,
806 rather than its internal branch table, thereby loading in the
807 existing value of the branch.</p></div>
811 the first ancestor of the current commit, and the branch will start
813 commit are permitted by fast-import, thereby establishing an n-way merge.
814 However Git's other tools never create commits with more than 15
815 additional ancestors (forming a 16-way merge). For this reason
818 <div class="para"><p>Here <tt><committish></tt> is any of the commit specification expressions
822 content of an existing file. This command has two different means
823 of specifying the content of the file.</p></div>
825 <dt>
826 External data format
827 </dt>
828 <dd>
829 <p>
830 The data content for the file was already supplied by a prior
832 </p>
836 </div></div>
837 <div class="para"><p>Here <tt><dataref></tt> can be either a mark reference (<tt>:<idnum></tt>)
839 existing Git blob object.</p></div>
840 </dd>
841 <dt>
842 Inline data format
843 </dt>
844 <dd>
845 <p>
846 The data content for the file has not been supplied yet.
847 The frontend wants to supply it as part of this modify
848 command.
849 </p>
853 data</tt></pre>
854 </div></div>
855 <div class="para"><p>See below for a detailed description of the <tt>data</tt> command.</p></div>
856 </dd>
857 </dl></div>
859 in octal. Git only supports the following modes:</p></div>
861 <li>
862 <p>
864 of files in most projects use this mode. If in doubt, this is
865 what you want.
866 </p>
867 </li>
868 <li>
869 <p>
871 </p>
872 </li>
873 <li>
874 <p>
876 </p>
877 </li>
878 <li>
879 <p>
881 another repository. Git links can only be specified by SHA or through
882 a commit mark. They are used to implement submodules.
883 </p>
884 </li>
885 </ul></div>
886 <div class="para"><p>In both formats <tt><path></tt> is the complete path of the file to be added
887 (if not already existing) or modified (if already existing).</p></div>
888 <div class="para"><p>A <tt><path></tt> string must use UNIX-style directory separators (forward
891 <div class="para"><p>If an <tt>LF</tt> or double quote must be encoded into <tt><path></tt> shell-style
893 <div class="para"><p>The value of <tt><path></tt> must be in canonical form. That is it must not:</p></div>
895 <li>
896 <p>
898 </p>
899 </li>
900 <li>
901 <p>
903 </p>
904 </li>
905 <li>
906 <p>
908 </p>
909 </li>
910 <li>
911 <p>
914 </p>
915 </li>
916 </ul></div>
917 <div class="para"><p>It is recommended that <tt><path></tt> always be encoded using UTF-8.</p></div>
920 delete an entire directory from the branch. If the file or directory
921 removal makes its parent directory empty, the parent directory will
922 be automatically removed too. This cascades up the tree until the
923 first non-empty directory or the root is reached.</p></div>
927 </div></div>
928 <div class="para"><p>here <tt><path></tt> is the complete path of the file or subdirectory to
929 be removed from the branch.
933 location within the branch. The existing file or directory must
934 exist. If the destination exists it will be completely replaced
935 by the content copied from the source.</p></div>
939 </div></div>
943 that contains SP the path must be quoted.</p></div>
945 location has been copied to the destination any future commands
946 applied to the source location will not impact the destination of
947 the copy.</p></div>
950 within the branch. The existing file or directory must exist. If
951 the destination exists it will be replaced by the source directory.</p></div>
955 </div></div>
959 that contains SP the path must be quoted.</p></div>
961 location has been renamed to the destination any future commands
962 applied to the source location will create new files there and not
963 impact the destination of the rename.</p></div>
964 <div class="para"><p>Note that a <tt>filerename</tt> is the same as a <tt>filecopy</tt> followed by a
967 that it is never worth trying to convert a delete/add pair in
969 command is provided just to simplify frontends that already have
970 rename information and don't want bother with decomposing it into a
974 directories) from the branch. This command resets the internal
975 branch structure to have no files in it, allowing the frontend
976 to subsequently add all interesting files from scratch.</p></div>
980 </div></div>
982 (or does not care to know) what files are currently on the branch,
984 update the content.</p></div>
985 <div class="para"><p>Issuing a <tt>filedeleteall</tt> followed by the needed <tt>filemodify</tt>
986 commands to set the correct content will produce the same results
989 more memory per active branch (less than 1 MiB for even most large
990 projects); so frontends that can easily obtain only the affected
991 paths for a commit are encouraged to do so.</p></div>
993 <div class="para"><p>Arranges for fast-import to save a reference to the current object, allowing
994 the frontend to recall this object at a future point in time, without
995 knowing its SHA-1. Here the current object is the object creation
1001 </div></div>
1002 <div class="para"><p>where <tt><idnum></tt> is the number assigned by the frontend to this mark.
1004 The value 0 is reserved and cannot be used as
1017 data</tt></pre>
1018 </div></div>
1024 <div class="para"><p>The value of <tt><name></tt> must be a valid refname in Git and therefore
1026 no quoting or escaping syntax is supported here.</p></div>
1027 <div class="para"><p>The <tt>from</tt> command is the same as in the <tt>commit</tt> command; see
1028 above for details.</p></div>
1029 <div class="para"><p>The <tt>tagger</tt> command uses the same format as <tt>committer</tt> within
1031 <div class="para"><p>The <tt>data</tt> command following <tt>tagger</tt> must supply the annotated tag
1033 tag message use a 0 length data. Tag messages are free-form and are
1034 not interpreted by Git. Currently they must be encoded in UTF-8,
1035 as fast-import does not permit other encodings to be specified.</p></div>
1037 supported. Trying to include your own PGP/GPG signature is not
1038 recommended, as the frontend does not (easily) have access to the
1039 complete set of bytes which normally goes into such a signature.
1040 If signing is required, create lightweight tags from within fast-import with
1045 a specific revision. The reset command allows a frontend to issue
1047 branch from an existing commit without creating a new commit.</p></div>
1052 LF?</tt></pre>
1053 </div></div>
1054 <div class="para"><p>For a detailed description of <tt><ref></tt> and <tt><committish></tt> see above
1056 <div class="para"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
1058 (non-annotated) tags. For example:</p></div>
1065 </div></div>
1066 </div></div>
1071 is not connected to any commit; this connection must be formed in
1073 assigned mark.</p></div>
1076 <pre><tt> 'blob' LF
1077 mark?
1078 data</tt></pre>
1079 </div></div>
1081 to generate the Git SHA-1 for the blob on their own, and feed that
1083 however, as marks are inexpensive to store and easy to use.</p></div>
1086 annotated tag messages) to fast-import. Data can be supplied using an exact
1087 byte count or delimited with a terminating line. Real frontends
1088 intended for production-quality conversions should always use the
1089 exact byte count format, as it is more robust and performs better.
1090 The delimited format is intended primarily for testing fast-import.</p></div>
1091 <div class="para"><p>Comment lines appearing within the <tt><raw></tt> part of <tt>data</tt> commands
1092 are always taken to be part of the body of the data and are therefore
1093 never ignored by fast-import. This makes it safe to import any
1096 <dt>
1097 Exact byte count format
1098 </dt>
1099 <dd>
1100 <p>
1101 The frontend must specify the number of bytes of data.
1102 </p>
1107 </div></div>
1108 <div class="para"><p>where <tt><count></tt> is the exact number of bytes appearing within
1112 <div class="para"><p>The <tt>LF</tt> after <tt><raw></tt> is optional (it used to be required) but
1113 recommended. Always including it makes debugging a fast-import
1114 stream easier as the next command always starts in column 0
1116 </dd>
1117 <dt>
1118 Delimited format
1119 </dt>
1120 <dd>
1121 <p>
1122 A delimiter string is used to mark the end of the data.
1123 fast-import will compute the length by searching for the delimiter.
1124 This format is primarily useful for testing and is not
1125 recommended for real data.
1126 </p>
1132 LF?</tt></pre>
1133 </div></div>
1134 <div class="para"><p>where <tt><delim></tt> is the chosen delimiter string. The string <tt><delim></tt>
1138 the limitations of the delimited format, it is impossible to supply
1139 a data chunk which does not have an LF as its last byte.</p></div>
1140 <div class="para"><p>The <tt>LF</tt> after <tt><delim> LF</tt> is optional (it used to be required).</p></div>
1141 </dd>
1142 </dl></div>
1145 save out all current branch refs, tags and marks.</p></div>
1148 <pre><tt> 'checkpoint' LF
1149 LF?</tt></pre>
1150 </div></div>
1152 packfile reaches --max-pack-size, or 4 GiB, whichever limit is
1153 smaller. During an automatic packfile switch fast-import does not update
1154 the branch refs, tags or marks.</p></div>
1156 disk IO (to compute the overall pack SHA-1 checksum, generate the
1157 corresponding index file, and update the refs) it can easily take
1160 and long running imports, or when they need to allow another Git
1161 process access to a branch. However given that a 30 GiB Subversion
1162 repository can be loaded into Git through fast-import in about 3 hours,
1163 explicit checkpointing may not be necessary.</p></div>
1164 <div class="para"><p>The <tt>LF</tt> after the command is optional (it used to be required).</p></div>
1166 <div class="para"><p>Causes fast-import to print the entire <tt>progress</tt> line unmodified to
1167 its standard output channel (file descriptor 1) when the command is
1168 processed from the input stream. The command otherwise has no impact
1169 on the current import, or on any of fast-import's internal state.</p></div>
1173 LF?</tt></pre>
1174 </div></div>
1175 <div class="para"><p>The <tt><any></tt> part of the command may contain any sequence of bytes
1177 Callers may wish to process the output through a tool such as sed to
1178 remove the leading part of the line, for example:</p></div>
1184 </div></div>
1185 </div></div>
1186 <div class="para"><p>Placing a <tt>progress</tt> command immediately after a <tt>checkpoint</tt> will
1188 can safely access the refs that fast-import updated.</p></div>
1189 </div>
1193 non-zero exit status and create a crash report in the top level of
1194 the Git repository it was importing into. Crash reports contain
1195 a snapshot of the internal fast-import state as well as the most
1196 recent commands that lead up to the crash.</p></div>
1198 progress commands) are shown in the command history within the crash
1199 report, but raw file data and commit messages are excluded from the
1200 crash report. This exclusion saves space within the report file
1201 and reduces the amount of buffering that fast-import must perform
1202 during execution.</p></div>
1204 packfile and export the marks table. This allows the frontend
1205 developer to inspect the repository state and resume the import from
1206 the point where it crashed. The modified branches and tags are not
1207 updated during a crash, as the import did not complete successfully.
1208 Branch and tag information can be found in the crash report and
1209 must be applied manually if the update is needed.</p></div>
1216 # my very first test commit
1217 commit refs/heads/master
1219 # who is that guy anyway?
1220 data <<EOF
1221 this is my commit
1222 EOF
1223 M 644 inline .gitignore
1224 data <<EOF
1225 .gitignore
1226 EOF
1227 M 777 inline bob
1228 END_OF_INPUT</tt></pre>
1229 </div></div>
1233 fatal: Corrupt mode: M 777 inline bob
1234 fast-import: dumping crash report to .git/fast_import_crash_8434</tt></pre>
1235 </div></div>
1238 <pre><tt>$ cat .git/fast_import_crash_8434
1239 fast-import crash report:
1240 fast-import process: 8434
1241 parent process : 1391
1243 </div></div>
1247 </div></div>
1250 <pre><tt>Most Recent Commands Before Crash
1251 ---------------------------------
1252 # my very first test commit
1253 commit refs/heads/master
1255 # who is that guy anyway?
1256 data <<EOF
1257 M 644 inline .gitignore
1258 data <<EOF
1260 </div></div>
1263 <pre><tt>Active Branch LRU
1264 -----------------
1266 </div></div>
1269 <pre><tt>pos clock name
1270 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1272 </div></div>
1275 <pre><tt>Inactive Branches
1276 -----------------
1277 refs/heads/master:
1278 status : active loaded dirty
1279 tip commit : 0000000000000000000000000000000000000000
1280 old tree : 0000000000000000000000000000000000000000
1281 cur tree : 0000000000000000000000000000000000000000
1282 commit clock: 0
1283 last pack :</tt></pre>
1284 </div></div>
1287 <pre><tt>-------------------
1288 END OF CRASH REPORT</tt></pre>
1289 </div></div>
1290 </div></div>
1291 </div>
1295 users of fast-import, and are offered here as suggestions.</p></div>
1299 line. fast-import will dump a file which lists every mark and the Git
1300 object SHA-1 that corresponds to it. If the frontend can tie
1301 the marks back to the source repository, it is easy to verify the
1302 accuracy and completeness of the import by comparing each Git
1303 commit to the corresponding source revision.</p></div>
1305 quite simple, as the fast-import mark can also be the Perforce changeset
1306 number or the Subversion revision number.</p></div>
1307 <h3 id="_freely_skip_around_branches">Freely Skip Around Branches</h3><div style="clear:left"></div>
1309 at a time during an import. Although doing so might be slightly
1310 faster for fast-import, it tends to increase the complexity of the frontend
1311 code considerably.</p></div>
1313 cost of activating an inactive branch is so low that bouncing around
1314 between branches has virtually no impact on import performance.</p></div>
1317 name(s) and modify the new name(s) during the corresponding commit.
1318 Git performs rename detection after-the-fact, rather than explicitly
1319 during a commit.</p></div>
1322 files which are not from the same commit/changeset. Or to create
1323 tags which are a subset of the files available in the repository.</p></div>
1327 outside of your normal branch space to the base commit for the tag,
1328 then commit one or more file fixup commits, and finally tag the
1329 dummy branch.</p></div>
1330 <div class="para"><p>For example since all normal branches are stored under <tt>refs/heads/</tt>
1332 the fixup branch used by the importer to have namespace conflicts
1336 commit(s) which are supplying file revisions to the fixup branch.
1338 through the real commit history and properly annotate the source
1339 files.</p></div>
1340 <div class="para"><p>After fast-import terminates the frontend will need to do <tt>rm .git/TAG_FIXUP</tt>
1341 to remove the dummy branch.</p></div>
1344 and ready for use. Typically this takes only a very short time,
1347 locality and access performance. It can also take hours on extremely
1348 large projects (especially if -f and a large --window parameter is
1349 used). Since repacking is safe to run alongside readers and writers,
1350 run the repack in the background and let it finish when it finishes.
1351 There is no reason to wait to explore your new Git project!</p></div>
1353 or performance tests until repacking is completed. fast-import outputs
1354 suboptimal packfiles that are simply never seen in real use
1355 situations.</p></div>
1356 <h3 id="_repacking_historical_data">Repacking Historical Data</h3><div style="clear:left"></div>
1358 last year), consider expending some extra CPU time and supplying
1360 This will take longer, but will also produce a smaller packfile.
1361 You only need to expend the effort once, and everyone using your
1362 project will benefit from the smaller repository.</p></div>
1363 <h3 id="_include_some_progress_messages">Include Some Progress Messages</h3><div style="clear:left"></div>
1365 to fast-import. The contents of the messages are entirely free-form,
1366 so one suggestion would be to output the current month and year
1367 each time the current commit date moves into the next month.
1368 Your users will feel better knowing how much of the data stream
1369 has been processed.</p></div>
1370 </div>
1373 <div class="para"><p>When packing a blob fast-import always attempts to deltify against the last
1374 blob written. Unless specifically arranged for by the frontend,
1375 this will probably not be a prior version of the same file, so the
1376 generated delta will not be the smallest possible. The resulting
1377 packfile will be compressed, but will not be optimal.</p></div>
1379 single file (for example reading an RCS/CVS ,v file) can choose
1380 to supply all revisions of that file as a sequence of consecutive
1382 revisions against each other, saving space in the final packfile.
1383 Marks can be used to later identify individual file revisions during
1386 patterns. This is caused by fast-import writing the data in the order
1387 it is received on standard input, while Git typically organizes
1388 data within packfiles to make the most recent (current tip) data
1389 appear before historical data. Git also clusters commits together,
1390 speeding up revision traversal through better cache locality.</p></div>
1393 Git to reorganize the packfiles for faster data access. If blob
1395 to force recomputation of all deltas can significantly reduce the
1397 </div>
1401 requires to perform an import. Like critical sections of core
1402 Git, fast-import uses its own memory allocators to amortize any overheads
1403 associated with malloc. In practice fast-import tends to amortize any
1409 pointer sizes). Objects in the table are not deallocated until
1413 (the unique SHA-1). This storage configuration allows fast-import to reuse
1414 an existing or already written object and avoid writing duplicates
1415 to the output packfile. Duplicate blobs are surprisingly common
1416 in an import, typically due to branch merges in the source.</p></div>
1419 bytes, depending on pointer size) per mark. Although the array
1420 is sparse, frontends are still strongly encouraged to use marks
1421 between 1 and n, where n is the total number of marks required for
1422 this import.</p></div>
1425 of the two classes is significantly different.</p></div>
1428 the branch name (typically under 200 bytes), per branch. fast-import will
1430 of memory.</p></div>
1432 also contain copies of every tree that has been recently modified on
1434 branch became active, its contents will not be loaded into memory,
1436 became active, then its contents will be loaded in memory.</p></div>
1438 branch, their in-memory storage size can grow to a considerable size
1439 (see below).</p></div>
1440 <div class="para"><p>fast-import automatically moves active branches to inactive status based on
1441 a simple least-recently-used algorithm. The LRU chain is updated on
1443 increased or decreased on the command line with --active-branches=.</p></div>
1447 The cost of a tree is virtually 0, as its overhead amortizes out
1448 over the individual file entries.</p></div>
1452 tree names are pooled in a common string table, allowing the filename
1454 overhead) no matter how many times it occurs within the project.</p></div>
1456 and lazy loading of subtrees, allows fast-import to efficiently import
1459 </div>
1463 </div>
1467 </div>
1471 </div>
1475 </div>
1476 </div>
1477 </body>
1478 </html>