t9020: which is not portable
[git/git.git] / Documentation / git-fast-import.txt
1 git-fast-import(1)
2 ==================
5 ----
6 git-fast-import - Backend for fast Git data importers
10 --------
11 [verse]
12 frontend | 'git fast-import' [options]
15 -----------
16 This program is usually not what the end user wants to run directly.
17 Most end users want to use one of the existing frontend programs,
18 which parses a specific type of foreign source and feeds the contents
19 stored there to 'git fast-import'.
21 fast-import reads a mixed command/data stream from standard input and
22 writes one or more packfiles directly into the current repository.
23 When EOF is received on standard input, fast import writes out
24 updated branch and tag refs, fully updating the current repository
25 with the newly imported data.
27 The fast-import backend itself can import into an empty repository (one that
28 has already been initialized by 'git init') or incrementally
29 update an existing populated repository. Whether or not incremental
30 imports are supported from a particular foreign source depends on
31 the frontend program in use.
35 -------
36 --date-format=<fmt>::
37 Specify the type of dates the frontend will supply to
38 fast-import within `author`, `committer` and `tagger` commands.
39 See ``Date Formats'' below for details about which formats
40 are supported, and their syntax.
42 --force::
43 Force updating modified existing branches, even if doing
44 so would cause commits to be lost (as the new commit does
45 not contain the old commit).
47 --max-pack-size=<n>::
48 Maximum size of each output packfile.
49 The default is unlimited.
51 --big-file-threshold=<n>::
52 Maximum size of a blob that fast-import will attempt to
53 create a delta for, expressed in bytes. The default is 512m
54 (512 MiB). Some importers may wish to lower this on systems
55 with constrained memory.
57 --depth=<n>::
58 Maximum delta depth, for blob and tree deltification.
59 Default is 10.
61 --active-branches=<n>::
62 Maximum number of branches to maintain active at once.
63 See ``Memory Utilization'' below for details. Default is 5.
65 --export-marks=<file>::
66 Dumps the internal marks table to <file> when complete.
67 Marks are written one per line as `:markid SHA-1`.
68 Frontends can use this file to validate imports after they
69 have been completed, or to save the marks table across
70 incremental runs. As <file> is only opened and truncated
71 at checkpoint (or completion) the same path can also be
72 safely given to \--import-marks.
74 --import-marks=<file>::
75 Before processing any input, load the marks specified in
76 <file>. The input file must exist, must be readable, and
77 must use the same format as produced by \--export-marks.
78 Multiple options may be supplied to import more than one
79 set of marks. If a mark is defined to different values,
80 the last file wins.
82 --import-marks-if-exists=<file>::
83 Like --import-marks but instead of erroring out, silently
84 skips the file if it does not exist.
86 --relative-marks::
87 After specifying --relative-marks the paths specified
88 with --import-marks= and --export-marks= are relative
89 to an internal directory in the current repository.
90 In git-fast-import this means that the paths are relative
91 to the .git/info/fast-import directory. However, other
92 importers may use a different location.
94 --no-relative-marks::
95 Negates a previous --relative-marks. Allows for combining
96 relative and non-relative marks by interweaving
97 --(no-)-relative-marks with the --(import|export)-marks=
98 options.
100 --cat-blob-fd=<fd>::
101 Write responses to `cat-blob` and `ls` queries to the
102 file descriptor <fd> instead of `stdout`. Allows `progress`
103 output intended for the end-user to be separated from other
104 output.
106 --done::
107 Require a `done` command at the end of the stream.
108 This option might be useful for detecting errors that
109 cause the frontend to terminate before it has started to
110 write a stream.
112 --export-pack-edges=<file>::
113 After creating a packfile, print a line of data to
114 <file> listing the filename of the packfile and the last
115 commit on each branch that was written to that packfile.
116 This information may be useful after importing projects
117 whose total object set exceeds the 4 GiB packfile limit,
118 as these commits can be used as edge points during calls
119 to 'git pack-objects'.
121 --quiet::
122 Disable all non-fatal output, making fast-import silent when it
123 is successful. This option disables the output shown by
124 \--stats.
126 --stats::
127 Display some basic statistics about the objects fast-import has
128 created, the packfiles they were stored into, and the
129 memory used by fast-import during this run. Showing this output
130 is currently the default, but can be disabled with \--quiet.
133 Performance
134 -----------
135 The design of fast-import allows it to import large projects in a minimum
136 amount of memory usage and processing time. Assuming the frontend
137 is able to keep up with fast-import and feed it a constant stream of data,
138 import times for projects holding 10+ years of history and containing
139 100,000+ individual commits are generally completed in just 1-2
140 hours on quite modest (~$2,000 USD) hardware.
142 Most bottlenecks appear to be in foreign source data access (the
143 source just cannot extract revisions fast enough) or disk IO (fast-import
144 writes as fast as the disk will take the data). Imports will run
145 faster if the source data is stored on a different drive than the
146 destination Git repository (due to less IO contention).
149 Development Cost
150 ----------------
151 A typical frontend for fast-import tends to weigh in at approximately 200
152 lines of Perl/Python/Ruby code. Most developers have been able to
153 create working importers in just a couple of hours, even though it
154 is their first exposure to fast-import, and sometimes even to Git. This is
155 an ideal situation, given that most conversion tools are throw-away
156 (use once, and never look back).
159 Parallel Operation
160 ------------------
161 Like 'git push' or 'git fetch', imports handled by fast-import are safe to
162 run alongside parallel `git repack -a -d` or `git gc` invocations,
163 or any other Git operation (including 'git prune', as loose objects
164 are never used by fast-import).
166 fast-import does not lock the branch or tag refs it is actively importing.
167 After the import, during its ref update phase, fast-import tests each
168 existing branch ref to verify the update will be a fast-forward
169 update (the commit stored in the ref is contained in the new
170 history of the commit to be written). If the update is not a
171 fast-forward update, fast-import will skip updating that ref and instead
172 prints a warning message. fast-import will always attempt to update all
173 branch refs, and does not stop on the first failure.
175 Branch updates can be forced with \--force, but it's recommended that
176 this only be used on an otherwise quiet repository. Using \--force
177 is not necessary for an initial import into an empty repository.
180 Technical Discussion
181 --------------------
182 fast-import tracks a set of branches in memory. Any branch can be created
183 or modified at any point during the import process by sending a
184 `commit` command on the input stream. This design allows a frontend
185 program to process an unlimited number of branches simultaneously,
186 generating commits in the order they are available from the source
187 data. It also simplifies the frontend programs considerably.
189 fast-import does not use or alter the current working directory, or any
190 file within it. (It does however update the current Git repository,
191 as referenced by `GIT_DIR`.) Therefore an import frontend may use
192 the working directory for its own purposes, such as extracting file
193 revisions from the foreign source. This ignorance of the working
194 directory also allows fast-import to run very quickly, as it does not
195 need to perform any costly file update operations when switching
196 between branches.
198 Input Format
199 ------------
200 With the exception of raw file data (which Git does not interpret)
201 the fast-import input format is text (ASCII) based. This text based
202 format simplifies development and debugging of frontend programs,
203 especially when a higher level language such as Perl, Python or
204 Ruby is being used.
206 fast-import is very strict about its input. Where we say SP below we mean
207 *exactly* one space. Likewise LF means one (and only one) linefeed
208 and HT one (and only one) horizontal tab.
209 Supplying additional whitespace characters will cause unexpected
210 results, such as branch names or file names with leading or trailing
211 spaces in their name, or early termination of fast-import when it encounters
212 unexpected input.
214 Stream Comments
215 ~~~~~~~~~~~~~~~
216 To aid in debugging frontends fast-import ignores any line that
217 begins with `#` (ASCII pound/hash) up to and including the line
218 ending `LF`. A comment line may contain any sequence of bytes
219 that does not contain an LF and therefore may be used to include
220 any detailed debugging information that might be specific to the
221 frontend and useful when inspecting a fast-import data stream.
223 Date Formats
224 ~~~~~~~~~~~~
225 The following date formats are supported. A frontend should select
226 the format it will use for this import by passing the format name
227 in the \--date-format=<fmt> command line option.
229 `raw`::
230 This is the Git native format and is `<time> SP <offutc>`.
231 It is also fast-import's default format, if \--date-format was
232 not specified.
233 +
234 The time of the event is specified by `<time>` as the number of
235 seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
236 written as an ASCII decimal integer.
237 +
238 The local offset is specified by `<offutc>` as a positive or negative
239 offset from UTC. For example EST (which is 5 hours behind UTC)
240 would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
241 The local offset does not affect `<time>`; it is used only as an
242 advisement to help formatting routines display the timestamp.
243 +
244 If the local offset is not available in the source material, use
245 ``+0000'', or the most common local offset. For example many
246 organizations have a CVS repository which has only ever been accessed
247 by users who are located in the same location and timezone. In this
248 case a reasonable offset from UTC could be assumed.
249 +
250 Unlike the `rfc2822` format, this format is very strict. Any
251 variation in formatting will cause fast-import to reject the value.
253 `rfc2822`::
254 This is the standard email format as described by RFC 2822.
255 +
256 An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
257 parser is accurate, but a little on the lenient side. It is the
258 same parser used by 'git am' when applying patches
259 received from email.
260 +
261 Some malformed strings may be accepted as valid dates. In some of
262 these cases Git will still be able to obtain the correct date from
263 the malformed string. There are also some types of malformed
264 strings which Git will parse wrong, and yet consider valid.
265 Seriously malformed strings will be rejected.
266 +
267 Unlike the `raw` format above, the timezone/UTC offset information
268 contained in an RFC 2822 date string is used to adjust the date
269 value to UTC prior to storage. Therefore it is important that
270 this information be as accurate as possible.
271 +
272 If the source material uses RFC 2822 style dates,
273 the frontend should let fast-import handle the parsing and conversion
274 (rather than attempting to do it itself) as the Git parser has
275 been well tested in the wild.
276 +
277 Frontends should prefer the `raw` format if the source material
278 already uses UNIX-epoch format, can be coaxed to give dates in that
279 format, or its format is easily convertible to it, as there is no
280 ambiguity in parsing.
282 `now`::
283 Always use the current time and timezone. The literal
284 `now` must always be supplied for `<when>`.
285 +
286 This is a toy format. The current time and timezone of this system
287 is always copied into the identity string at the time it is being
288 created by fast-import. There is no way to specify a different time or
289 timezone.
290 +
291 This particular format is supplied as it's short to implement and
292 may be useful to a process that wants to create a new commit
293 right now, without needing to use a working directory or
294 'git update-index'.
295 +
296 If separate `author` and `committer` commands are used in a `commit`
297 the timestamps may not match, as the system clock will be polled
298 twice (once for each command). The only way to ensure that both
299 author and committer identity information has the same timestamp
300 is to omit `author` (thus copying from `committer`) or to use a
301 date format other than `now`.
303 Commands
304 ~~~~~~~~
305 fast-import accepts several commands to update the current repository
306 and control the current import process. More detailed discussion
307 (with examples) of each command follows later.
309 `commit`::
310 Creates a new branch or updates an existing branch by
311 creating a new commit and updating the branch to point at
312 the newly created commit.
314 `tag`::
315 Creates an annotated tag object from an existing commit or
316 branch. Lightweight tags are not supported by this command,
317 as they are not recommended for recording meaningful points
318 in time.
320 `reset`::
321 Reset an existing branch (or a new branch) to a specific
322 revision. This command must be used to change a branch to
323 a specific revision without making a commit on it.
325 `blob`::
326 Convert raw file data into a blob, for future use in a
327 `commit` command. This command is optional and is not
328 needed to perform an import.
330 `checkpoint`::
331 Forces fast-import to close the current packfile, generate its
332 unique SHA-1 checksum and index, and start a new packfile.
333 This command is optional and is not needed to perform
334 an import.
336 `progress`::
337 Causes fast-import to echo the entire line to its own
338 standard output. This command is optional and is not needed
339 to perform an import.
341 `done`::
342 Marks the end of the stream. This command is optional
343 unless the `done` feature was requested using the
344 `--done` command line option or `feature done` command.
346 `cat-blob`::
347 Causes fast-import to print a blob in 'cat-file --batch'
348 format to the file descriptor set with `--cat-blob-fd` or
349 `stdout` if unspecified.
351 `ls`::
352 Causes fast-import to print a line describing a directory
353 entry in 'ls-tree' format to the file descriptor set with
354 `--cat-blob-fd` or `stdout` if unspecified.
356 `feature`::
357 Require that fast-import supports the specified feature, or
358 abort if it does not.
360 `option`::
361 Specify any of the options listed under OPTIONS that do not
362 change stream semantic to suit the frontend's needs. This
363 command is optional and is not needed to perform an import.
365 `commit`
366 ~~~~~~~~
367 Create or update a branch with a new commit, recording one logical
368 change to the project.
370 ....
371 'commit' SP <ref> LF
372 mark?
373 ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
374 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
375 data
376 ('from' SP <committish> LF)?
377 ('merge' SP <committish> LF)?
378 (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
379 LF?
380 ....
382 where `<ref>` is the name of the branch to make the commit on.
383 Typically branch names are prefixed with `refs/heads/` in
384 Git, so importing the CVS branch symbol `RELENG-1_0` would use
385 `refs/heads/RELENG-1_0` for the value of `<ref>`. The value of
386 `<ref>` must be a valid refname in Git. As `LF` is not valid in
387 a Git refname, no quoting or escaping syntax is supported here.
389 A `mark` command may optionally appear, requesting fast-import to save a
390 reference to the newly created commit for future use by the frontend
391 (see below for format). It is very common for frontends to mark
392 every commit they create, thereby allowing future branch creation
393 from any imported commit.
395 The `data` command following `committer` must supply the commit
396 message (see below for `data` command syntax). To import an empty
397 commit message use a 0 length data. Commit messages are free-form
398 and are not interpreted by Git. Currently they must be encoded in
399 UTF-8, as fast-import does not permit other encodings to be specified.
401 Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`,
402 `filedeleteall` and `notemodify` commands
403 may be included to update the contents of the branch prior to
404 creating the commit. These commands may be supplied in any order.
405 However it is recommended that a `filedeleteall` command precede
406 all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in
407 the same commit, as `filedeleteall` wipes the branch clean (see below).
409 The `LF` after the command is optional (it used to be required).
411 `author`
412 ^^^^^^^^
413 An `author` command may optionally appear, if the author information
414 might differ from the committer information. If `author` is omitted
415 then fast-import will automatically use the committer's information for
416 the author portion of the commit. See below for a description of
417 the fields in `author`, as they are identical to `committer`.
419 `committer`
420 ^^^^^^^^^^^
421 The `committer` command indicates who made this commit, and when
422 they made it.
424 Here `<name>` is the person's display name (for example
425 ``Com M Itter'') and `<email>` is the person's email address
426 (``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
427 and greater-than (\x3e) symbols. These are required to delimit
428 the email address from the other fields in the line. Note that
429 `<name>` and `<email>` are free-form and may contain any sequence
430 of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded.
432 The time of the change is specified by `<when>` using the date format
433 that was selected by the \--date-format=<fmt> command line option.
434 See ``Date Formats'' above for the set of supported formats, and
435 their syntax.
437 `from`
438 ^^^^^^
439 The `from` command is used to specify the commit to initialize
440 this branch from. This revision will be the first ancestor of the
441 new commit.
443 Omitting the `from` command in the first commit of a new branch
444 will cause fast-import to create that commit with no ancestor. This
445 tends to be desired only for the initial commit of a project.
446 If the frontend creates all files from scratch when making a new
447 branch, a `merge` command may be used instead of `from` to start
448 the commit with an empty tree.
449 Omitting the `from` command on existing branches is usually desired,
450 as the current commit on that branch is automatically assumed to
451 be the first ancestor of the new commit.
453 As `LF` is not valid in a Git refname or SHA-1 expression, no
454 quoting or escaping syntax is supported within `<committish>`.
456 Here `<committish>` is any of the following:
458 * The name of an existing branch already in fast-import's internal branch
459 table. If fast-import doesn't know the name, it's treated as a SHA-1
460 expression.
462 * A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
463 +
464 The reason fast-import uses `:` to denote a mark reference is this character
465 is not legal in a Git branch name. The leading `:` makes it easy
466 to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
467 or `refs/heads/42`), or an abbreviated SHA-1 which happened to
468 consist only of base-10 digits.
469 +
470 Marks must be declared (via `mark`) before they can be used.
472 * A complete 40 byte or abbreviated commit SHA-1 in hex.
474 * Any valid Git SHA-1 expression that resolves to a commit. See
475 ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
477 The special case of restarting an incremental import from the
478 current branch value should be written as:
479 ----
480 from refs/heads/branch^0
481 ----
482 The `^0` suffix is necessary as fast-import does not permit a branch to
483 start from itself, and the branch is created in memory before the
484 `from` command is even read from the input. Adding `^0` will force
485 fast-import to resolve the commit through Git's revision parsing library,
486 rather than its internal branch table, thereby loading in the
487 existing value of the branch.
489 `merge`
490 ^^^^^^^
491 Includes one additional ancestor commit. If the `from` command is
492 omitted when creating a new branch, the first `merge` commit will be
493 the first ancestor of the current commit, and the branch will start
494 out with no files. An unlimited number of `merge` commands per
495 commit are permitted by fast-import, thereby establishing an n-way merge.
496 However Git's other tools never create commits with more than 15
497 additional ancestors (forming a 16-way merge). For this reason
498 it is suggested that frontends do not use more than 15 `merge`
499 commands per commit; 16, if starting a new, empty branch.
501 Here `<committish>` is any of the commit specification expressions
502 also accepted by `from` (see above).
504 `filemodify`
505 ^^^^^^^^^^^^
506 Included in a `commit` command to add a new file or change the
507 content of an existing file. This command has two different means
508 of specifying the content of the file.
510 External data format::
511 The data content for the file was already supplied by a prior
512 `blob` command. The frontend just needs to connect it.
513 +
514 ....
515 'M' SP <mode> SP <dataref> SP <path> LF
516 ....
517 +
518 Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
519 set by a prior `blob` command, or a full 40-byte SHA-1 of an
520 existing Git blob object. If `<mode>` is `040000`` then
521 `<dataref>` must be the full 40-byte SHA-1 of an existing
522 Git tree object or a mark reference set with `--import-marks`.
524 Inline data format::
525 The data content for the file has not been supplied yet.
526 The frontend wants to supply it as part of this modify
527 command.
528 +
529 ....
530 'M' SP <mode> SP 'inline' SP <path> LF
531 data
532 ....
533 +
534 See below for a detailed description of the `data` command.
536 In both formats `<mode>` is the type of file entry, specified
537 in octal. Git only supports the following modes:
539 * `100644` or `644`: A normal (not-executable) file. The majority
540 of files in most projects use this mode. If in doubt, this is
541 what you want.
542 * `100755` or `755`: A normal, but executable, file.
543 * `120000`: A symlink, the content of the file will be the link target.
544 * `160000`: A gitlink, SHA-1 of the object refers to a commit in
545 another repository. Git links can only be specified by SHA or through
546 a commit mark. They are used to implement submodules.
547 * `040000`: A subdirectory. Subdirectories can only be specified by
548 SHA or through a tree mark set with `--import-marks`.
550 In both formats `<path>` is the complete path of the file to be added
551 (if not already existing) or modified (if already existing).
553 A `<path>` string must use UNIX-style directory separators (forward
554 slash `/`), may contain any byte other than `LF`, and must not
555 start with double quote (`"`).
557 If an `LF` or double quote must be encoded into `<path>` shell-style
558 quoting should be used, e.g. `"path/with\n and \" in it"`.
560 The value of `<path>` must be in canonical form. That is it must not:
562 * contain an empty directory component (e.g. `foo//bar` is invalid),
563 * end with a directory separator (e.g. `foo/` is invalid),
564 * start with a directory separator (e.g. `/foo` is invalid),
565 * contain the special component `.` or `..` (e.g. `foo/./bar` and
566 `foo/../bar` are invalid).
568 The root of the tree can be represented by an empty string as `<path>`.
570 It is recommended that `<path>` always be encoded using UTF-8.
572 `filedelete`
573 ^^^^^^^^^^^^
574 Included in a `commit` command to remove a file or recursively
575 delete an entire directory from the branch. If the file or directory
576 removal makes its parent directory empty, the parent directory will
577 be automatically removed too. This cascades up the tree until the
578 first non-empty directory or the root is reached.
580 ....
581 'D' SP <path> LF
582 ....
584 here `<path>` is the complete path of the file or subdirectory to
585 be removed from the branch.
586 See `filemodify` above for a detailed description of `<path>`.
588 `filecopy`
589 ^^^^^^^^^^^^
590 Recursively copies an existing file or subdirectory to a different
591 location within the branch. The existing file or directory must
592 exist. If the destination exists it will be completely replaced
593 by the content copied from the source.
595 ....
596 'C' SP <path> SP <path> LF
597 ....
599 here the first `<path>` is the source location and the second
600 `<path>` is the destination. See `filemodify` above for a detailed
601 description of what `<path>` may look like. To use a source path
602 that contains SP the path must be quoted.
604 A `filecopy` command takes effect immediately. Once the source
605 location has been copied to the destination any future commands
606 applied to the source location will not impact the destination of
607 the copy.
609 `filerename`
610 ^^^^^^^^^^^^
611 Renames an existing file or subdirectory to a different location
612 within the branch. The existing file or directory must exist. If
613 the destination exists it will be replaced by the source directory.
615 ....
616 'R' SP <path> SP <path> LF
617 ....
619 here the first `<path>` is the source location and the second
620 `<path>` is the destination. See `filemodify` above for a detailed
621 description of what `<path>` may look like. To use a source path
622 that contains SP the path must be quoted.
624 A `filerename` command takes effect immediately. Once the source
625 location has been renamed to the destination any future commands
626 applied to the source location will create new files there and not
627 impact the destination of the rename.
629 Note that a `filerename` is the same as a `filecopy` followed by a
630 `filedelete` of the source location. There is a slight performance
631 advantage to using `filerename`, but the advantage is so small
632 that it is never worth trying to convert a delete/add pair in
633 source material into a rename for fast-import. This `filerename`
634 command is provided just to simplify frontends that already have
635 rename information and don't want bother with decomposing it into a
636 `filecopy` followed by a `filedelete`.
638 `filedeleteall`
639 ^^^^^^^^^^^^^^^
640 Included in a `commit` command to remove all files (and also all
641 directories) from the branch. This command resets the internal
642 branch structure to have no files in it, allowing the frontend
643 to subsequently add all interesting files from scratch.
645 ....
646 'deleteall' LF
647 ....
649 This command is extremely useful if the frontend does not know
650 (or does not care to know) what files are currently on the branch,
651 and therefore cannot generate the proper `filedelete` commands to
652 update the content.
654 Issuing a `filedeleteall` followed by the needed `filemodify`
655 commands to set the correct content will produce the same results
656 as sending only the needed `filemodify` and `filedelete` commands.
657 The `filedeleteall` approach may however require fast-import to use slightly
658 more memory per active branch (less than 1 MiB for even most large
659 projects); so frontends that can easily obtain only the affected
660 paths for a commit are encouraged to do so.
662 `notemodify`
663 ^^^^^^^^^^^^
664 Included in a `commit` `<notes_ref>` command to add a new note
665 annotating a `<committish>` or change this annotation contents.
666 Internally it is similar to filemodify 100644 on `<committish>`
667 path (maybe split into subdirectories). It's not advised to
668 use any other commands to write to the `<notes_ref>` tree except
669 `filedeleteall` to delete all existing notes in this tree.
670 This command has two different means of specifying the content
671 of the note.
673 External data format::
674 The data content for the note was already supplied by a prior
675 `blob` command. The frontend just needs to connect it to the
676 commit that is to be annotated.
677 +
678 ....
679 'N' SP <dataref> SP <committish> LF
680 ....
681 +
682 Here `<dataref>` can be either a mark reference (`:<idnum>`)
683 set by a prior `blob` command, or a full 40-byte SHA-1 of an
684 existing Git blob object.
686 Inline data format::
687 The data content for the note has not been supplied yet.
688 The frontend wants to supply it as part of this modify
689 command.
690 +
691 ....
692 'N' SP 'inline' SP <committish> LF
693 data
694 ....
695 +
696 See below for a detailed description of the `data` command.
698 In both formats `<committish>` is any of the commit specification
699 expressions also accepted by `from` (see above).
701 `mark`
702 ~~~~~~
703 Arranges for fast-import to save a reference to the current object, allowing
704 the frontend to recall this object at a future point in time, without
705 knowing its SHA-1. Here the current object is the object creation
706 command the `mark` command appears within. This can be `commit`,
707 `tag`, and `blob`, but `commit` is the most common usage.
709 ....
710 'mark' SP ':' <idnum> LF
711 ....
713 where `<idnum>` is the number assigned by the frontend to this mark.
714 The value of `<idnum>` is expressed as an ASCII decimal integer.
715 The value 0 is reserved and cannot be used as
716 a mark. Only values greater than or equal to 1 may be used as marks.
718 New marks are created automatically. Existing marks can be moved
719 to another object simply by reusing the same `<idnum>` in another
720 `mark` command.
722 `tag`
723 ~~~~~
724 Creates an annotated tag referring to a specific commit. To create
725 lightweight (non-annotated) tags see the `reset` command below.
727 ....
728 'tag' SP <name> LF
729 'from' SP <committish> LF
730 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
731 data
732 ....
734 where `<name>` is the name of the tag to create.
736 Tag names are automatically prefixed with `refs/tags/` when stored
737 in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
738 use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
739 corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
741 The value of `<name>` must be a valid refname in Git and therefore
742 may contain forward slashes. As `LF` is not valid in a Git refname,
743 no quoting or escaping syntax is supported here.
745 The `from` command is the same as in the `commit` command; see
746 above for details.
748 The `tagger` command uses the same format as `committer` within
749 `commit`; again see above for details.
751 The `data` command following `tagger` must supply the annotated tag
752 message (see below for `data` command syntax). To import an empty
753 tag message use a 0 length data. Tag messages are free-form and are
754 not interpreted by Git. Currently they must be encoded in UTF-8,
755 as fast-import does not permit other encodings to be specified.
757 Signing annotated tags during import from within fast-import is not
758 supported. Trying to include your own PGP/GPG signature is not
759 recommended, as the frontend does not (easily) have access to the
760 complete set of bytes which normally goes into such a signature.
761 If signing is required, create lightweight tags from within fast-import with
762 `reset`, then create the annotated versions of those tags offline
763 with the standard 'git tag' process.
765 `reset`
766 ~~~~~~~
767 Creates (or recreates) the named branch, optionally starting from
768 a specific revision. The reset command allows a frontend to issue
769 a new `from` command for an existing branch, or to create a new
770 branch from an existing commit without creating a new commit.
772 ....
773 'reset' SP <ref> LF
774 ('from' SP <committish> LF)?
775 LF?
776 ....
778 For a detailed description of `<ref>` and `<committish>` see above
779 under `commit` and `from`.
781 The `LF` after the command is optional (it used to be required).
783 The `reset` command can also be used to create lightweight
784 (non-annotated) tags. For example:
786 ====
787 reset refs/tags/938
788 from :938
789 ====
791 would create the lightweight tag `refs/tags/938` referring to
792 whatever commit mark `:938` references.
794 `blob`
795 ~~~~~~
796 Requests writing one file revision to the packfile. The revision
797 is not connected to any commit; this connection must be formed in
798 a subsequent `commit` command by referencing the blob through an
799 assigned mark.
801 ....
802 'blob' LF
803 mark?
804 data
805 ....
807 The mark command is optional here as some frontends have chosen
808 to generate the Git SHA-1 for the blob on their own, and feed that
809 directly to `commit`. This is typically more work than it's worth
810 however, as marks are inexpensive to store and easy to use.
812 `data`
813 ~~~~~~
814 Supplies raw data (for use as blob/file content, commit messages, or
815 annotated tag messages) to fast-import. Data can be supplied using an exact
816 byte count or delimited with a terminating line. Real frontends
817 intended for production-quality conversions should always use the
818 exact byte count format, as it is more robust and performs better.
819 The delimited format is intended primarily for testing fast-import.
821 Comment lines appearing within the `<raw>` part of `data` commands
822 are always taken to be part of the body of the data and are therefore
823 never ignored by fast-import. This makes it safe to import any
824 file/message content whose lines might start with `#`.
826 Exact byte count format::
827 The frontend must specify the number of bytes of data.
828 +
829 ....
830 'data' SP <count> LF
831 <raw> LF?
832 ....
833 +
834 where `<count>` is the exact number of bytes appearing within
835 `<raw>`. The value of `<count>` is expressed as an ASCII decimal
836 integer. The `LF` on either side of `<raw>` is not
837 included in `<count>` and will not be included in the imported data.
838 +
839 The `LF` after `<raw>` is optional (it used to be required) but
840 recommended. Always including it makes debugging a fast-import
841 stream easier as the next command always starts in column 0
842 of the next line, even if `<raw>` did not end with an `LF`.
844 Delimited format::
845 A delimiter string is used to mark the end of the data.
846 fast-import will compute the length by searching for the delimiter.
847 This format is primarily useful for testing and is not
848 recommended for real data.
849 +
850 ....
851 'data' SP '<<' <delim> LF
852 <raw> LF
853 <delim> LF
854 LF?
855 ....
856 +
857 where `<delim>` is the chosen delimiter string. The string `<delim>`
858 must not appear on a line by itself within `<raw>`, as otherwise
859 fast-import will think the data ends earlier than it really does. The `LF`
860 immediately trailing `<raw>` is part of `<raw>`. This is one of
861 the limitations of the delimited format, it is impossible to supply
862 a data chunk which does not have an LF as its last byte.
863 +
864 The `LF` after `<delim> LF` is optional (it used to be required).
866 `checkpoint`
867 ~~~~~~~~~~~~
868 Forces fast-import to close the current packfile, start a new one, and to
869 save out all current branch refs, tags and marks.
871 ....
872 'checkpoint' LF
873 LF?
874 ....
876 Note that fast-import automatically switches packfiles when the current
877 packfile reaches \--max-pack-size, or 4 GiB, whichever limit is
878 smaller. During an automatic packfile switch fast-import does not update
879 the branch refs, tags or marks.
881 As a `checkpoint` can require a significant amount of CPU time and
882 disk IO (to compute the overall pack SHA-1 checksum, generate the
883 corresponding index file, and update the refs) it can easily take
884 several minutes for a single `checkpoint` command to complete.
886 Frontends may choose to issue checkpoints during extremely large
887 and long running imports, or when they need to allow another Git
888 process access to a branch. However given that a 30 GiB Subversion
889 repository can be loaded into Git through fast-import in about 3 hours,
890 explicit checkpointing may not be necessary.
892 The `LF` after the command is optional (it used to be required).
894 `progress`
895 ~~~~~~~~~~
896 Causes fast-import to print the entire `progress` line unmodified to
897 its standard output channel (file descriptor 1) when the command is
898 processed from the input stream. The command otherwise has no impact
899 on the current import, or on any of fast-import's internal state.
901 ....
902 'progress' SP <any> LF
903 LF?
904 ....
906 The `<any>` part of the command may contain any sequence of bytes
907 that does not contain `LF`. The `LF` after the command is optional.
908 Callers may wish to process the output through a tool such as sed to
909 remove the leading part of the line, for example:
911 ====
912 frontend | git fast-import | sed 's/^progress //'
913 ====
915 Placing a `progress` command immediately after a `checkpoint` will
916 inform the reader when the `checkpoint` has been completed and it
917 can safely access the refs that fast-import updated.
919 `cat-blob`
920 ~~~~~~~~~~
921 Causes fast-import to print a blob to a file descriptor previously
922 arranged with the `--cat-blob-fd` argument. The command otherwise
923 has no impact on the current import; its main purpose is to
924 retrieve blobs that may be in fast-import's memory but not
925 accessible from the target repository.
927 ....
928 'cat-blob' SP <dataref> LF
929 ....
931 The `<dataref>` can be either a mark reference (`:<idnum>`)
932 set previously or a full 40-byte SHA-1 of a Git blob, preexisting or
933 ready to be written.
935 Output uses the same format as `git cat-file --batch`:
937 ====
938 <sha1> SP 'blob' SP <size> LF
939 <contents> LF
940 ====
942 This command can be used anywhere in the stream that comments are
943 accepted. In particular, the `cat-blob` command can be used in the
944 middle of a commit but not in the middle of a `data` command.
946 See ``Responses To Commands'' below for details about how to read
947 this output safely.
949 `ls`
950 ~~~~
951 Prints information about the object at a path to a file descriptor
952 previously arranged with the `--cat-blob-fd` argument. This allows
953 printing a blob from the active commit (with `cat-blob`) or copying a
954 blob or tree from a previous commit for use in the current one (with
955 `filemodify`).
957 The `ls` command can be used anywhere in the stream that comments are
958 accepted, including the middle of a commit.
960 Reading from the active commit::
961 This form can only be used in the middle of a `commit`.
962 The path names a directory entry within fast-import's
963 active commit. The path must be quoted in this case.
964 +
965 ....
966 'ls' SP <path> LF
967 ....
969 Reading from a named tree::
970 The `<dataref>` can be a mark reference (`:<idnum>`) or the
971 full 40-byte SHA-1 of a Git tag, commit, or tree object,
972 preexisting or waiting to be written.
973 The path is relative to the top level of the tree
974 named by `<dataref>`.
975 +
976 ....
977 'ls' SP <dataref> SP <path> LF
978 ....
980 See `filemodify` above for a detailed description of `<path>`.
982 Output uses the same format as `git ls-tree <tree> -- <path>`:
984 ====
985 <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF
986 ====
988 The <dataref> represents the blob, tree, or commit object at <path>
989 and can be used in later 'cat-blob', 'filemodify', or 'ls' commands.
991 If there is no file or subtree at that path, 'git fast-import' will
992 instead report
994 ====
995 missing SP <path> LF
996 ====
998 See ``Responses To Commands'' below for details about how to read
999 this output safely.
1001 `feature`
1002 ~~~~~~~~~
1003 Require that fast-import supports the specified feature, or abort if
1004 it does not.
1006 ....
1007 'feature' SP <feature> ('=' <argument>)? LF
1008 ....
1010 The <feature> part of the command may be any one of the following:
1012 date-format::
1013 export-marks::
1014 relative-marks::
1015 no-relative-marks::
1016 force::
1017 Act as though the corresponding command-line option with
1018 a leading '--' was passed on the command line
1019 (see OPTIONS, above).
1021 import-marks::
1022 import-marks-if-exists::
1023 Like --import-marks except in two respects: first, only one
1024 "feature import-marks" or "feature import-marks-if-exists"
1025 command is allowed per stream; second, an --import-marks=
1026 or --import-marks-if-exists command-line option overrides
1027 any of these "feature" commands in the stream; third,
1028 "feature import-marks-if-exists" like a corresponding
1029 command-line option silently skips a nonexistent file.
1031 cat-blob::
1032 ls::
1033 Require that the backend support the 'cat-blob' or 'ls' command.
1034 Versions of fast-import not supporting the specified command
1035 will exit with a message indicating so.
1036 This lets the import error out early with a clear message,
1037 rather than wasting time on the early part of an import
1038 before the unsupported command is detected.
1040 notes::
1041 Require that the backend support the 'notemodify' (N)
1042 subcommand to the 'commit' command.
1043 Versions of fast-import not supporting notes will exit
1044 with a message indicating so.
1046 done::
1047 Error out if the stream ends without a 'done' command.
1048 Without this feature, errors causing the frontend to end
1049 abruptly at a convenient point in the stream can go
1050 undetected.
1052 `option`
1053 ~~~~~~~~
1054 Processes the specified option so that git fast-import behaves in a
1055 way that suits the frontend's needs.
1056 Note that options specified by the frontend are overridden by any
1057 options the user may specify to git fast-import itself.
1059 ....
1060 'option' SP <option> LF
1061 ....
1063 The `<option>` part of the command may contain any of the options
1064 listed in the OPTIONS section that do not change import semantics,
1065 without the leading '--' and is treated in the same way.
1067 Option commands must be the first commands on the input (not counting
1068 feature commands), to give an option command after any non-option
1069 command is an error.
1071 The following commandline options change import semantics and may therefore
1072 not be passed as option:
1074 * date-format
1075 * import-marks
1076 * export-marks
1077 * cat-blob-fd
1078 * force
1080 `done`
1081 ~~~~~~
1082 If the `done` feature is not in use, treated as if EOF was read.
1083 This can be used to tell fast-import to finish early.
1085 If the `--done` command line option or `feature done` command is
1086 in use, the `done` command is mandatory and marks the end of the
1087 stream.
1089 Responses To Commands
1090 ---------------------
1091 New objects written by fast-import are not available immediately.
1092 Most fast-import commands have no visible effect until the next
1093 checkpoint (or completion). The frontend can send commands to
1094 fill fast-import's input pipe without worrying about how quickly
1095 they will take effect, which improves performance by simplifying
1096 scheduling.
1098 For some frontends, though, it is useful to be able to read back
1099 data from the current repository as it is being updated (for
1100 example when the source material describes objects in terms of
1101 patches to be applied to previously imported objects). This can
1102 be accomplished by connecting the frontend and fast-import via
1103 bidirectional pipes:
1105 ====
1106 mkfifo fast-import-output
1107 frontend <fast-import-output |
1108 git fast-import >fast-import-output
1109 ====
1111 A frontend set up this way can use `progress`, `ls`, and `cat-blob`
1112 commands to read information from the import in progress.
1114 To avoid deadlock, such frontends must completely consume any
1115 pending output from `progress`, `ls`, and `cat-blob` before
1116 performing writes to fast-import that might block.
1118 Crash Reports
1119 -------------
1120 If fast-import is supplied invalid input it will terminate with a
1121 non-zero exit status and create a crash report in the top level of
1122 the Git repository it was importing into. Crash reports contain
1123 a snapshot of the internal fast-import state as well as the most
1124 recent commands that lead up to the crash.
1126 All recent commands (including stream comments, file changes and
1127 progress commands) are shown in the command history within the crash
1128 report, but raw file data and commit messages are excluded from the
1129 crash report. This exclusion saves space within the report file
1130 and reduces the amount of buffering that fast-import must perform
1131 during execution.
1133 After writing a crash report fast-import will close the current
1134 packfile and export the marks table. This allows the frontend
1135 developer to inspect the repository state and resume the import from
1136 the point where it crashed. The modified branches and tags are not
1137 updated during a crash, as the import did not complete successfully.
1138 Branch and tag information can be found in the crash report and
1139 must be applied manually if the update is needed.
1141 An example crash:
1143 ====
1144 $ cat >in <<END_OF_INPUT
1145 # my very first test commit
1146 commit refs/heads/master
1147 committer Shawn O. Pearce <spearce> 19283 -0400
1148 # who is that guy anyway?
1149 data <<EOF
1150 this is my commit
1151 EOF
1152 M 644 inline .gitignore
1153 data <<EOF
1154 .gitignore
1155 EOF
1156 M 777 inline bob
1159 $ git fast-import <in
1160 fatal: Corrupt mode: M 777 inline bob
1161 fast-import: dumping crash report to .git/fast_import_crash_8434
1163 $ cat .git/fast_import_crash_8434
1164 fast-import crash report:
1165 fast-import process: 8434
1166 parent process : 1391
1167 at Sat Sep 1 00:58:12 2007
1169 fatal: Corrupt mode: M 777 inline bob
1171 Most Recent Commands Before Crash
1172 ---------------------------------
1173 # my very first test commit
1174 commit refs/heads/master
1175 committer Shawn O. Pearce <spearce> 19283 -0400
1176 # who is that guy anyway?
1177 data <<EOF
1178 M 644 inline .gitignore
1179 data <<EOF
1180 * M 777 inline bob
1182 Active Branch LRU
1183 -----------------
1184 active_branches = 1 cur, 5 max
1186 pos clock name
1187 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1188 1) 0 refs/heads/master
1190 Inactive Branches
1191 -----------------
1192 refs/heads/master:
1193 status : active loaded dirty
1194 tip commit : 0000000000000000000000000000000000000000
1195 old tree : 0000000000000000000000000000000000000000
1196 cur tree : 0000000000000000000000000000000000000000
1197 commit clock: 0
1198 last pack :
1201 -------------------
1203 ====
1205 Tips and Tricks
1206 ---------------
1207 The following tips and tricks have been collected from various
1208 users of fast-import, and are offered here as suggestions.
1210 Use One Mark Per Commit
1211 ~~~~~~~~~~~~~~~~~~~~~~~
1212 When doing a repository conversion, use a unique mark per commit
1213 (`mark :<n>`) and supply the \--export-marks option on the command
1214 line. fast-import will dump a file which lists every mark and the Git
1215 object SHA-1 that corresponds to it. If the frontend can tie
1216 the marks back to the source repository, it is easy to verify the
1217 accuracy and completeness of the import by comparing each Git
1218 commit to the corresponding source revision.
1220 Coming from a system such as Perforce or Subversion this should be
1221 quite simple, as the fast-import mark can also be the Perforce changeset
1222 number or the Subversion revision number.
1224 Freely Skip Around Branches
1225 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1226 Don't bother trying to optimize the frontend to stick to one branch
1227 at a time during an import. Although doing so might be slightly
1228 faster for fast-import, it tends to increase the complexity of the frontend
1229 code considerably.
1231 The branch LRU builtin to fast-import tends to behave very well, and the
1232 cost of activating an inactive branch is so low that bouncing around
1233 between branches has virtually no impact on import performance.
1235 Handling Renames
1236 ~~~~~~~~~~~~~~~~
1237 When importing a renamed file or directory, simply delete the old
1238 name(s) and modify the new name(s) during the corresponding commit.
1239 Git performs rename detection after-the-fact, rather than explicitly
1240 during a commit.
1242 Use Tag Fixup Branches
1243 ~~~~~~~~~~~~~~~~~~~~~~
1244 Some other SCM systems let the user create a tag from multiple
1245 files which are not from the same commit/changeset. Or to create
1246 tags which are a subset of the files available in the repository.
1248 Importing these tags as-is in Git is impossible without making at
1249 least one commit which ``fixes up'' the files to match the content
1250 of the tag. Use fast-import's `reset` command to reset a dummy branch
1251 outside of your normal branch space to the base commit for the tag,
1252 then commit one or more file fixup commits, and finally tag the
1253 dummy branch.
1255 For example since all normal branches are stored under `refs/heads/`
1256 name the tag fixup branch `TAG_FIXUP`. This way it is impossible for
1257 the fixup branch used by the importer to have namespace conflicts
1258 with real branches imported from the source (the name `TAG_FIXUP`
1259 is not `refs/heads/TAG_FIXUP`).
1261 When committing fixups, consider using `merge` to connect the
1262 commit(s) which are supplying file revisions to the fixup branch.
1263 Doing so will allow tools such as 'git blame' to track
1264 through the real commit history and properly annotate the source
1265 files.
1267 After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP`
1268 to remove the dummy branch.
1270 Import Now, Repack Later
1271 ~~~~~~~~~~~~~~~~~~~~~~~~
1272 As soon as fast-import completes the Git repository is completely valid
1273 and ready for use. Typically this takes only a very short time,
1274 even for considerably large projects (100,000+ commits).
1276 However repacking the repository is necessary to improve data
1277 locality and access performance. It can also take hours on extremely
1278 large projects (especially if -f and a large \--window parameter is
1279 used). Since repacking is safe to run alongside readers and writers,
1280 run the repack in the background and let it finish when it finishes.
1281 There is no reason to wait to explore your new Git project!
1283 If you choose to wait for the repack, don't try to run benchmarks
1284 or performance tests until repacking is completed. fast-import outputs
1285 suboptimal packfiles that are simply never seen in real use
1286 situations.
1288 Repacking Historical Data
1289 ~~~~~~~~~~~~~~~~~~~~~~~~~
1290 If you are repacking very old imported data (e.g. older than the
1291 last year), consider expending some extra CPU time and supplying
1292 \--window=50 (or higher) when you run 'git repack'.
1293 This will take longer, but will also produce a smaller packfile.
1294 You only need to expend the effort once, and everyone using your
1295 project will benefit from the smaller repository.
1297 Include Some Progress Messages
1298 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1299 Every once in a while have your frontend emit a `progress` message
1300 to fast-import. The contents of the messages are entirely free-form,
1301 so one suggestion would be to output the current month and year
1302 each time the current commit date moves into the next month.
1303 Your users will feel better knowing how much of the data stream
1304 has been processed.
1307 Packfile Optimization
1308 ---------------------
1309 When packing a blob fast-import always attempts to deltify against the last
1310 blob written. Unless specifically arranged for by the frontend,
1311 this will probably not be a prior version of the same file, so the
1312 generated delta will not be the smallest possible. The resulting
1313 packfile will be compressed, but will not be optimal.
1315 Frontends which have efficient access to all revisions of a
1316 single file (for example reading an RCS/CVS ,v file) can choose
1317 to supply all revisions of that file as a sequence of consecutive
1318 `blob` commands. This allows fast-import to deltify the different file
1319 revisions against each other, saving space in the final packfile.
1320 Marks can be used to later identify individual file revisions during
1321 a sequence of `commit` commands.
1323 The packfile(s) created by fast-import do not encourage good disk access
1324 patterns. This is caused by fast-import writing the data in the order
1325 it is received on standard input, while Git typically organizes
1326 data within packfiles to make the most recent (current tip) data
1327 appear before historical data. Git also clusters commits together,
1328 speeding up revision traversal through better cache locality.
1330 For this reason it is strongly recommended that users repack the
1331 repository with `git repack -a -d` after fast-import completes, allowing
1332 Git to reorganize the packfiles for faster data access. If blob
1333 deltas are suboptimal (see above) then also adding the `-f` option
1334 to force recomputation of all deltas can significantly reduce the
1335 final packfile size (30-50% smaller can be quite typical).
1338 Memory Utilization
1339 ------------------
1340 There are a number of factors which affect how much memory fast-import
1341 requires to perform an import. Like critical sections of core
1342 Git, fast-import uses its own memory allocators to amortize any overheads
1343 associated with malloc. In practice fast-import tends to amortize any
1344 malloc overheads to 0, due to its use of large block allocations.
1346 per object
1347 ~~~~~~~~~~
1348 fast-import maintains an in-memory structure for every object written in
1349 this execution. On a 32 bit system the structure is 32 bytes,
1350 on a 64 bit system the structure is 40 bytes (due to the larger
1351 pointer sizes). Objects in the table are not deallocated until
1352 fast-import terminates. Importing 2 million objects on a 32 bit system
1353 will require approximately 64 MiB of memory.
1355 The object table is actually a hashtable keyed on the object name
1356 (the unique SHA-1). This storage configuration allows fast-import to reuse
1357 an existing or already written object and avoid writing duplicates
1358 to the output packfile. Duplicate blobs are surprisingly common
1359 in an import, typically due to branch merges in the source.
1361 per mark
1362 ~~~~~~~~
1363 Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
1364 bytes, depending on pointer size) per mark. Although the array
1365 is sparse, frontends are still strongly encouraged to use marks
1366 between 1 and n, where n is the total number of marks required for
1367 this import.
1369 per branch
1370 ~~~~~~~~~~
1371 Branches are classified as active and inactive. The memory usage
1372 of the two classes is significantly different.
1374 Inactive branches are stored in a structure which uses 96 or 120
1375 bytes (32 bit or 64 bit systems, respectively), plus the length of
1376 the branch name (typically under 200 bytes), per branch. fast-import will
1377 easily handle as many as 10,000 inactive branches in under 2 MiB
1378 of memory.
1380 Active branches have the same overhead as inactive branches, but
1381 also contain copies of every tree that has been recently modified on
1382 that branch. If subtree `include` has not been modified since the
1383 branch became active, its contents will not be loaded into memory,
1384 but if subtree `src` has been modified by a commit since the branch
1385 became active, then its contents will be loaded in memory.
1387 As active branches store metadata about the files contained on that
1388 branch, their in-memory storage size can grow to a considerable size
1389 (see below).
1391 fast-import automatically moves active branches to inactive status based on
1392 a simple least-recently-used algorithm. The LRU chain is updated on
1393 each `commit` command. The maximum number of active branches can be
1394 increased or decreased on the command line with \--active-branches=.
1396 per active tree
1397 ~~~~~~~~~~~~~~~
1398 Trees (aka directories) use just 12 bytes of memory on top of the
1399 memory required for their entries (see ``per active file'' below).
1400 The cost of a tree is virtually 0, as its overhead amortizes out
1401 over the individual file entries.
1403 per active file entry
1404 ~~~~~~~~~~~~~~~~~~~~~
1405 Files (and pointers to subtrees) within active trees require 52 or 64
1406 bytes (32/64 bit platforms) per entry. To conserve space, file and
1407 tree names are pooled in a common string table, allowing the filename
1408 ``Makefile'' to use just 16 bytes (after including the string header
1409 overhead) no matter how many times it occurs within the project.
1411 The active branch LRU, when coupled with the filename string pool
1412 and lazy loading of subtrees, allows fast-import to efficiently import
1413 projects with 2,000+ branches and 45,114+ files in a very limited
1414 memory footprint (less than 2.7 MiB per active branch).
1416 Signals
1417 -------
1418 Sending *SIGUSR1* to the 'git fast-import' process ends the current
1419 packfile early, simulating a `checkpoint` command. The impatient
1420 operator can use this facility to peek at the objects and refs from an
1421 import in progress, at the cost of some added running time and worse
1422 compression.
1424 GIT
1425 ---
1426 Part of the linkgit:git[1] suite