freshlybakedca.ke
Git fork
1git-fast-import(1)
2==================
3
4NAME
5----
6git-fast-import - Backend for fast Git data importers
7
8
9SYNOPSIS
10--------
11[verse]
12frontend | 'git fast-import' [<options>]
13
14DESCRIPTION
15-----------
16This program is usually not what the end user wants to run directly.
17Most end users want to use one of the existing frontend programs,
18which parses a specific type of foreign source and feeds the contents
19stored there to 'git fast-import'.
20
21fast-import reads a mixed command/data stream from standard input and
22writes one or more packfiles directly into the current repository.
23When EOF is received on standard input, fast import writes out
24updated branch and tag refs, fully updating the current repository
25with the newly imported data.
26
27The fast-import backend itself can import into an empty repository (one that
28has already been initialized by 'git init') or incrementally
29update an existing populated repository. Whether or not incremental
30imports are supported from a particular foreign source depends on
31the frontend program in use.
32
33
34OPTIONS
35-------
36
37--force::
38 Force updating modified existing branches, even if doing
39 so would cause commits to be lost (as the new commit does
40 not contain the old commit).
41
42--quiet::
43 Disable the output shown by --stats, making fast-import usually
44 be silent when it is successful. However, if the import stream
45 has directives intended to show user output (e.g. `progress`
46 directives), the corresponding messages will still be shown.
47
48--stats::
49 Display some basic statistics about the objects fast-import has
50 created, the packfiles they were stored into, and the
51 memory used by fast-import during this run. Showing this output
52 is currently the default, but can be disabled with --quiet.
53
54--allow-unsafe-features::
55 Many command-line options can be provided as part of the
56 fast-import stream itself by using the `feature` or `option`
57 commands. However, some of these options are unsafe (e.g.,
58 allowing fast-import to access the filesystem outside of the
59 repository). These options are disabled by default, but can be
60 allowed by providing this option on the command line. This
61 currently impacts only the `export-marks`, `import-marks`, and
62 `import-marks-if-exists` feature commands.
63+
64Only enable this option if you trust the program generating the
65fast-import stream! This option is enabled automatically for
66remote-helpers that use the `import` capability, as they are
67already trusted to run their own code.
68
69--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)::
70 Specify how to handle signed tags. Behaves in the same way
71 as the same option in linkgit:git-fast-export[1], except that
72 default is 'verbatim' (instead of 'abort').
73
74--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)::
75 Specify how to handle signed commits. Behaves in the same way
76 as the same option in linkgit:git-fast-export[1], except that
77 default is 'verbatim' (instead of 'abort').
78
79Options for Frontends
80~~~~~~~~~~~~~~~~~~~~~
81
82--cat-blob-fd=<fd>::
83 Write responses to `get-mark`, `cat-blob`, and `ls` queries to the
84 file descriptor <fd> instead of `stdout`. Allows `progress`
85 output intended for the end-user to be separated from other
86 output.
87
88--date-format=<fmt>::
89 Specify the type of dates the frontend will supply to
90 fast-import within `author`, `committer` and `tagger` commands.
91 See ``Date Formats'' below for details about which formats
92 are supported, and their syntax.
93
94--done::
95 Terminate with error if there is no `done` command at the end of
96 the stream. This option might be useful for detecting errors
97 that cause the frontend to terminate before it has started to
98 write a stream.
99
100Locations of Marks Files
101~~~~~~~~~~~~~~~~~~~~~~~~
102
103--export-marks=<file>::
104 Dumps the internal marks table to <file> when complete.
105 Marks are written one per line as `:markid SHA-1`.
106 Frontends can use this file to validate imports after they
107 have been completed, or to save the marks table across
108 incremental runs. As <file> is only opened and truncated
109 at checkpoint (or completion) the same path can also be
110 safely given to --import-marks.
111
112--import-marks=<file>::
113 Before processing any input, load the marks specified in
114 <file>. The input file must exist, must be readable, and
115 must use the same format as produced by --export-marks.
116 Multiple options may be supplied to import more than one
117 set of marks. If a mark is defined to different values,
118 the last file wins.
119
120--import-marks-if-exists=<file>::
121 Like --import-marks but instead of erroring out, silently
122 skips the file if it does not exist.
123
124--relative-marks::
125--no-relative-marks::
126 After specifying --relative-marks the paths specified
127 with --import-marks= and --export-marks= are relative
128 to an internal directory in the current repository.
129 In git-fast-import this means that the paths are relative
130 to the .git/info/fast-import directory. However, other
131 importers may use a different location.
132+
133Relative and non-relative marks may be combined by interweaving
134--(no-)-relative-marks with the --(import|export)-marks= options.
135
136Submodule Rewriting
137~~~~~~~~~~~~~~~~~~~
138
139--rewrite-submodules-from=<name>:<file>::
140--rewrite-submodules-to=<name>:<file>::
141 Rewrite the object IDs for the submodule specified by <name> from the values
142 used in the from <file> to those used in the to <file>. The from marks should
143 have been created by `git fast-export`, and the to marks should have been
144 created by `git fast-import` when importing that same submodule.
145+
146<name> may be any arbitrary string not containing a colon character, but the
147same value must be used with both options when specifying corresponding marks.
148Multiple submodules may be specified with different values for <name>. It is an
149error not to use these options in corresponding pairs.
150+
151These options are primarily useful when converting a repository from one hash
152algorithm to another; without them, fast-import will fail if it encounters a
153submodule because it has no way of writing the object ID into the new hash
154algorithm.
155
156Performance and Compression Tuning
157~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
158
159--active-branches=<n>::
160 Maximum number of branches to maintain active at once.
161 See ``Memory Utilization'' below for details. Default is 5.
162
163--big-file-threshold=<n>::
164 Maximum size of a blob that fast-import will attempt to
165 create a delta for, expressed in bytes. The default is 512m
166 (512 MiB). Some importers may wish to lower this on systems
167 with constrained memory.
168
169--depth=<n>::
170 Maximum delta depth, for blob and tree deltification.
171 Default is 50.
172
173--export-pack-edges=<file>::
174 After creating a packfile, print a line of data to
175 <file> listing the filename of the packfile and the last
176 commit on each branch that was written to that packfile.
177 This information may be useful after importing projects
178 whose total object set exceeds the 4 GiB packfile limit,
179 as these commits can be used as edge points during calls
180 to 'git pack-objects'.
181
182--max-pack-size=<n>::
183 Maximum size of each output packfile.
184 The default is unlimited.
185
186fastimport.unpackLimit::
187 See linkgit:git-config[1]
188
189PERFORMANCE
190-----------
191The design of fast-import allows it to import large projects in a minimum
192amount of memory usage and processing time. Assuming the frontend
193is able to keep up with fast-import and feed it a constant stream of data,
194import times for projects holding 10+ years of history and containing
195100,000+ individual commits are generally completed in just 1-2
196hours on quite modest hardware (~$2,000 USD in 2007).
197
198Most bottlenecks appear to be in foreign source data access (the
199source just cannot extract revisions fast enough) or disk IO (fast-import
200writes as fast as the disk will take the data). Imports will run
201faster if the source data is stored on a different drive than the
202destination Git repository (due to less IO contention).
203
204
205DEVELOPMENT COST
206----------------
207A typical frontend for fast-import tends to weigh in at approximately 200
208lines of Perl/Python/Ruby code. Most developers have been able to
209create working importers in just a couple of hours, even though it
210is their first exposure to fast-import, and sometimes even to Git. This is
211an ideal situation, given that most conversion tools are throw-away
212(use once, and never look back).
213
214
215PARALLEL OPERATION
216------------------
217Like 'git push' or 'git fetch', imports handled by fast-import are safe to
218run alongside parallel `git repack -a -d` or `git gc` invocations,
219or any other Git operation (including 'git prune', as loose objects
220are never used by fast-import).
221
222fast-import does not lock the branch or tag refs it is actively importing.
223After the import, during its ref update phase, fast-import tests each
224existing branch ref to verify the update will be a fast-forward
225update (the commit stored in the ref is contained in the new
226history of the commit to be written). If the update is not a
227fast-forward update, fast-import will skip updating that ref and instead
228prints a warning message. fast-import will always attempt to update all
229branch refs, and does not stop on the first failure.
230
231Branch updates can be forced with --force, but it's recommended that
232this only be used on an otherwise quiet repository. Using --force
233is not necessary for an initial import into an empty repository.
234
235
236TECHNICAL DISCUSSION
237--------------------
238fast-import tracks a set of branches in memory. Any branch can be created
239or modified at any point during the import process by sending a
240`commit` command on the input stream. This design allows a frontend
241program to process an unlimited number of branches simultaneously,
242generating commits in the order they are available from the source
243data. It also simplifies the frontend programs considerably.
244
245fast-import does not use or alter the current working directory, or any
246file within it. (It does however update the current Git repository,
247as referenced by `GIT_DIR`.) Therefore an import frontend may use
248the working directory for its own purposes, such as extracting file
249revisions from the foreign source. This ignorance of the working
250directory also allows fast-import to run very quickly, as it does not
251need to perform any costly file update operations when switching
252between branches.
253
254INPUT FORMAT
255------------
256With the exception of raw file data (which Git does not interpret)
257the fast-import input format is text (ASCII) based. This text based
258format simplifies development and debugging of frontend programs,
259especially when a higher level language such as Perl, Python or
260Ruby is being used.
261
262fast-import is very strict about its input. Where we say SP below we mean
263*exactly* one space. Likewise LF means one (and only one) linefeed
264and HT one (and only one) horizontal tab.
265Supplying additional whitespace characters will cause unexpected
266results, such as branch names or file names with leading or trailing
267spaces in their name, or early termination of fast-import when it encounters
268unexpected input.
269
270Stream Comments
271~~~~~~~~~~~~~~~
272To aid in debugging frontends fast-import ignores any line that
273begins with `#` (ASCII pound/hash) up to and including the line
274ending `LF`. A comment line may contain any sequence of bytes
275that does not contain an LF and therefore may be used to include
276any detailed debugging information that might be specific to the
277frontend and useful when inspecting a fast-import data stream.
278
279Date Formats
280~~~~~~~~~~~~
281The following date formats are supported. A frontend should select
282the format it will use for this import by passing the format name
283in the --date-format=<fmt> command-line option.
284
285`raw`::
286 This is the Git native format and is `<time> SP <offutc>`.
287 It is also fast-import's default format, if --date-format was
288 not specified.
289+
290The time of the event is specified by `<time>` as the number of
291seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
292written as an ASCII decimal integer.
293+
294The local offset is specified by `<offutc>` as a positive or negative
295offset from UTC. For example EST (which is 5 hours behind UTC)
296would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
297The local offset does not affect `<time>`; it is used only as an
298advisement to help formatting routines display the timestamp.
299+
300If the local offset is not available in the source material, use
301``+0000'', or the most common local offset. For example many
302organizations have a CVS repository which has only ever been accessed
303by users who are located in the same location and time zone. In this
304case a reasonable offset from UTC could be assumed.
305+
306Unlike the `rfc2822` format, this format is very strict. Any
307variation in formatting will cause fast-import to reject the value,
308and some sanity checks on the numeric values may also be performed.
309
310`raw-permissive`::
311 This is the same as `raw` except that no sanity checks on
312 the numeric epoch and local offset are performed. This can
313 be useful when trying to filter or import an existing history
314 with e.g. bogus timezone values.
315
316`rfc2822`::
317 This is the standard date format as described by RFC 2822.
318+
319An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
320parser is accurate, but a little on the lenient side. It is the
321same parser used by 'git am' when applying patches
322received from email.
323+
324Some malformed strings may be accepted as valid dates. In some of
325these cases Git will still be able to obtain the correct date from
326the malformed string. There are also some types of malformed
327strings which Git will parse wrong, and yet consider valid.
328Seriously malformed strings will be rejected.
329+
330Unlike the `raw` format above, the time zone/UTC offset information
331contained in an RFC 2822 date string is used to adjust the date
332value to UTC prior to storage. Therefore it is important that
333this information be as accurate as possible.
334+
335If the source material uses RFC 2822 style dates,
336the frontend should let fast-import handle the parsing and conversion
337(rather than attempting to do it itself) as the Git parser has
338been well tested in the wild.
339+
340Frontends should prefer the `raw` format if the source material
341already uses UNIX-epoch format, can be coaxed to give dates in that
342format, or its format is easily convertible to it, as there is no
343ambiguity in parsing.
344
345`now`::
346 Always use the current time and time zone. The literal
347 `now` must always be supplied for `<when>`.
348+
349This is a toy format. The current time and time zone of this system
350is always copied into the identity string at the time it is being
351created by fast-import. There is no way to specify a different time or
352time zone.
353+
354This particular format is supplied as it's short to implement and
355may be useful to a process that wants to create a new commit
356right now, without needing to use a working directory or
357'git update-index'.
358+
359If separate `author` and `committer` commands are used in a `commit`
360the timestamps may not match, as the system clock will be polled
361twice (once for each command). The only way to ensure that both
362author and committer identity information has the same timestamp
363is to omit `author` (thus copying from `committer`) or to use a
364date format other than `now`.
365
366Commands
367~~~~~~~~
368fast-import accepts several commands to update the current repository
369and control the current import process. More detailed discussion
370(with examples) of each command follows later.
371
372`commit`::
373 Creates a new branch or updates an existing branch by
374 creating a new commit and updating the branch to point at
375 the newly created commit.
376
377`tag`::
378 Creates an annotated tag object from an existing commit or
379 branch. Lightweight tags are not supported by this command,
380 as they are not recommended for recording meaningful points
381 in time.
382
383`reset`::
384 Reset an existing branch (or a new branch) to a specific
385 revision. This command must be used to change a branch to
386 a specific revision without making a commit on it.
387
388`blob`::
389 Convert raw file data into a blob, for future use in a
390 `commit` command. This command is optional and is not
391 needed to perform an import.
392
393`alias`::
394 Record that a mark refers to a given object without first
395 creating any new object. Using --import-marks and referring
396 to missing marks will cause fast-import to fail, so aliases
397 can provide a way to set otherwise pruned commits to a valid
398 value (e.g. the nearest non-pruned ancestor).
399
400`checkpoint`::
401 Forces fast-import to close the current packfile, generate its
402 unique SHA-1 checksum and index, and start a new packfile.
403 This command is optional and is not needed to perform
404 an import.
405
406`progress`::
407 Causes fast-import to echo the entire line to its own
408 standard output. This command is optional and is not needed
409 to perform an import.
410
411`done`::
412 Marks the end of the stream. This command is optional
413 unless the `done` feature was requested using the
414 `--done` command-line option or `feature done` command.
415
416`get-mark`::
417 Causes fast-import to print the SHA-1 corresponding to a mark
418 to the file descriptor set with `--cat-blob-fd`, or `stdout` if
419 unspecified.
420
421`cat-blob`::
422 Causes fast-import to print a blob in 'cat-file --batch'
423 format to the file descriptor set with `--cat-blob-fd` or
424 `stdout` if unspecified.
425
426`ls`::
427 Causes fast-import to print a line describing a directory
428 entry in 'ls-tree' format to the file descriptor set with
429 `--cat-blob-fd` or `stdout` if unspecified.
430
431`feature`::
432 Enable the specified feature. This requires that fast-import
433 supports the specified feature, and aborts if it does not.
434
435`option`::
436 Specify any of the options listed under OPTIONS that do not
437 change stream semantic to suit the frontend's needs. This
438 command is optional and is not needed to perform an import.
439
440`commit`
441~~~~~~~~
442Create or update a branch with a new commit, recording one logical
443change to the project.
444
445////
446Yes, it's intentional that the 'gpgsig' line doesn't have a trailing
447`LF`; the definition of `data` has a byte-count prefix, so it
448doesn't need an `LF` to act as a terminator (and `data` also already
449includes an optional trailing `LF?` just in case you want to include
450one).
451////
452
453....
454 'commit' SP <ref> LF
455 mark?
456 original-oid?
457 ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
458 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
459 ('gpgsig' SP <algo> SP <format> LF data)?
460 ('encoding' SP <encoding> LF)?
461 data
462 ('from' SP <commit-ish> LF)?
463 ('merge' SP <commit-ish> LF)*
464 (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
465 LF?
466....
467
468where `<ref>` is the name of the branch to make the commit on.
469Typically branch names are prefixed with `refs/heads/` in
470Git, so importing the CVS branch symbol `RELENG-1_0` would use
471`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of
472`<ref>` must be a valid refname in Git. As `LF` is not valid in
473a Git refname, no quoting or escaping syntax is supported here.
474
475A `mark` command may optionally appear, requesting fast-import to save a
476reference to the newly created commit for future use by the frontend
477(see below for format). It is very common for frontends to mark
478every commit they create, thereby allowing future branch creation
479from any imported commit.
480
481The `data` command following `committer` must supply the commit
482message (see below for `data` command syntax). To import an empty
483commit message use a 0 length data. Commit messages are free-form
484and are not interpreted by Git. Currently they must be encoded in
485UTF-8, as fast-import does not permit other encodings to be specified.
486
487Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`,
488`filedeleteall` and `notemodify` commands
489may be included to update the contents of the branch prior to
490creating the commit. These commands may be supplied in any order.
491However it is recommended that a `filedeleteall` command precede
492all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in
493the same commit, as `filedeleteall` wipes the branch clean (see below).
494
495The `LF` after the command is optional (it used to be required). Note
496that for reasons of backward compatibility, if the commit ends with a
497`data` command (i.e. it has no `from`, `merge`, `filemodify`,
498`filedelete`, `filecopy`, `filerename`, `filedeleteall` or
499`notemodify` commands) then two `LF` commands may appear at the end of
500the command instead of just one.
501
502`author`
503^^^^^^^^
504An `author` command may optionally appear, if the author information
505might differ from the committer information. If `author` is omitted
506then fast-import will automatically use the committer's information for
507the author portion of the commit. See below for a description of
508the fields in `author`, as they are identical to `committer`.
509
510`committer`
511^^^^^^^^^^^
512The `committer` command indicates who made this commit, and when
513they made it.
514
515Here `<name>` is the person's display name (for example
516``Com M Itter'') and `<email>` is the person's email address
517(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
518and greater-than (\x3e) symbols. These are required to delimit
519the email address from the other fields in the line. Note that
520`<name>` and `<email>` are free-form and may contain any sequence
521of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded.
522
523The time of the change is specified by `<when>` using the date format
524that was selected by the --date-format=<fmt> command-line option.
525See ``Date Formats'' above for the set of supported formats, and
526their syntax.
527
528`gpgsig`
529^^^^^^^^
530
531The optional `gpgsig` command is used to include a PGP/GPG signature
532or other cryptographic signature that signs the commit data.
533
534....
535 'gpgsig' SP <git-hash-algo> SP <signature-format> LF data
536....
537
538The `gpgsig` command takes two arguments:
539
540* `<git-hash-algo>` specifies which Git object format this signature
541 applies to, either `sha1` or `sha256`. This allows to know which
542 representation of the commit was signed (the SHA-1 or the SHA-256
543 version) which helps with both signature verification and
544 interoperability between repos with different hash functions.
545
546* `<signature-format>` specifies the type of signature, such as
547 `openpgp`, `x509`, `ssh`, or `unknown`. This is a convenience for
548 tools that process the stream, so they don't have to parse the ASCII
549 armor to identify the signature type.
550
551A commit may have at most one signature for the SHA-1 object format
552(stored in the "gpgsig" header) and one for the SHA-256 object format
553(stored in the "gpgsig-sha256" header).
554
555See below for a detailed description of the `data` command which
556contains the raw signature data.
557
558Signatures are not yet checked in the current implementation
559though. (Already setting the `extensions.compatObjectFormat`
560configuration option might help with verifying both SHA-1 and SHA-256
561object format signatures when it will be implemented.)
562
563NOTE: This is highly experimental and the format of the `gpgsig`
564command may change in the future without compatibility guarantees.
565
566`encoding`
567^^^^^^^^^^
568The optional `encoding` command indicates the encoding of the commit
569message. Most commits are UTF-8 and the encoding is omitted, but this
570allows importing commit messages into git without first reencoding them.
571
572`from`
573^^^^^^
574The `from` command is used to specify the commit to initialize
575this branch from. This revision will be the first ancestor of the
576new commit. The state of the tree built at this commit will begin
577with the state at the `from` commit, and be altered by the content
578modifications in this commit.
579
580Omitting the `from` command in the first commit of a new branch
581will cause fast-import to create that commit with no ancestor. This
582tends to be desired only for the initial commit of a project.
583If the frontend creates all files from scratch when making a new
584branch, a `merge` command may be used instead of `from` to start
585the commit with an empty tree.
586Omitting the `from` command on existing branches is usually desired,
587as the current commit on that branch is automatically assumed to
588be the first ancestor of the new commit.
589
590As `LF` is not valid in a Git refname or SHA-1 expression, no
591quoting or escaping syntax is supported within `<commit-ish>`.
592
593Here `<commit-ish>` is any of the following:
594
595* The name of an existing branch already in fast-import's internal branch
596 table. If fast-import doesn't know the name, it's treated as a SHA-1
597 expression.
598
599* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
600+
601The reason fast-import uses `:` to denote a mark reference is this character
602is not legal in a Git branch name. The leading `:` makes it easy
603to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
604or `refs/heads/42`), or an abbreviated SHA-1 which happened to
605consist only of base-10 digits.
606+
607Marks must be declared (via `mark`) before they can be used.
608
609* A complete 40 byte or abbreviated commit SHA-1 in hex.
610
611* Any valid Git SHA-1 expression that resolves to a commit. See
612 ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
613
614* The special null SHA-1 (40 zeros) specifies that the branch is to be
615 removed.
616
617The special case of restarting an incremental import from the
618current branch value should be written as:
619
620----
621 from refs/heads/branch^0
622----
623
624The `^0` suffix is necessary as fast-import does not permit a branch to
625start from itself, and the branch is created in memory before the
626`from` command is even read from the input. Adding `^0` will force
627fast-import to resolve the commit through Git's revision parsing library,
628rather than its internal branch table, thereby loading in the
629existing value of the branch.
630
631`merge`
632^^^^^^^
633Includes one additional ancestor commit. The additional ancestry
634link does not change the way the tree state is built at this commit.
635If the `from` command is
636omitted when creating a new branch, the first `merge` commit will be
637the first ancestor of the current commit, and the branch will start
638out with no files. An unlimited number of `merge` commands per
639commit are permitted by fast-import, thereby establishing an n-way merge.
640
641Here `<commit-ish>` is any of the commit specification expressions
642also accepted by `from` (see above).
643
644`filemodify`
645^^^^^^^^^^^^
646Included in a `commit` command to add a new file or change the
647content of an existing file. This command has two different means
648of specifying the content of the file.
649
650External data format::
651 The data content for the file was already supplied by a prior
652 `blob` command. The frontend just needs to connect it.
653+
654....
655 'M' SP <mode> SP <dataref> SP <path> LF
656....
657+
658Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
659set by a prior `blob` command, or a full 40-byte SHA-1 of an
660existing Git blob object. If `<mode>` is `040000` then
661`<dataref>` must be the full 40-byte SHA-1 of an existing
662Git tree object or a mark reference set with `--import-marks`.
663
664Inline data format::
665 The data content for the file has not been supplied yet.
666 The frontend wants to supply it as part of this modify
667 command.
668+
669....
670 'M' SP <mode> SP 'inline' SP <path> LF
671 data
672....
673+
674See below for a detailed description of the `data` command.
675
676In both formats `<mode>` is the type of file entry, specified
677in octal. Git only supports the following modes:
678
679* `100644` or `644`: A normal (not-executable) file. The majority
680 of files in most projects use this mode. If in doubt, this is
681 what you want.
682* `100755` or `755`: A normal, but executable, file.
683* `120000`: A symlink, the content of the file will be the link target.
684* `160000`: A gitlink, SHA-1 of the object refers to a commit in
685 another repository. Git links can only be specified either by SHA or through
686 a commit mark. They are used to implement submodules.
687* `040000`: A subdirectory. Subdirectories can only be specified by
688 SHA or through a tree mark set with `--import-marks`.
689
690In both formats `<path>` is the complete path of the file to be added
691(if not already existing) or modified (if already existing).
692
693A `<path>` can be written as unquoted bytes or a C-style quoted string.
694
695When a `<path>` does not start with a double quote (`"`), it is an
696unquoted string and is parsed as literal bytes without any escape
697sequences. However, if the filename contains `LF` or starts with double
698quote, it cannot be represented as an unquoted string and must be
699quoted. Additionally, the source `<path>` in `filecopy` or `filerename`
700must be quoted if it contains SP.
701
702When a `<path>` starts with a double quote (`"`), it is a C-style quoted
703string, where the complete filename is enclosed in a pair of double
704quotes and escape sequences are used. Certain characters must be escaped
705by preceding them with a backslash: `LF` is written as `\n`, backslash
706as `\\`, and double quote as `\"`. Some characters may optionally be
707written with escape sequences: `\a` for bell, `\b` for backspace, `\f`
708for form feed, `\n` for line feed, `\r` for carriage return, `\t` for
709horizontal tab, and `\v` for vertical tab. Any byte can be written with
7103-digit octal codes (e.g., `\033`). All filenames can be represented as
711quoted strings.
712
713A `<path>` must use UNIX-style directory separators (forward slash `/`)
714and its value must be in canonical form. That is it must not:
715
716* contain an empty directory component (e.g. `foo//bar` is invalid),
717* end with a directory separator (e.g. `foo/` is invalid),
718* start with a directory separator (e.g. `/foo` is invalid),
719* contain the special component `.` or `..` (e.g. `foo/./bar` and
720 `foo/../bar` are invalid).
721
722The root of the tree can be represented by an empty string as `<path>`.
723
724`<path>` cannot contain NUL, either literally or escaped as `\000`.
725It is recommended that `<path>` always be encoded using UTF-8.
726
727`filedelete`
728^^^^^^^^^^^^
729Included in a `commit` command to remove a file or recursively
730delete an entire directory from the branch. If the file or directory
731removal makes its parent directory empty, the parent directory will
732be automatically removed too. This cascades up the tree until the
733first non-empty directory or the root is reached.
734
735....
736 'D' SP <path> LF
737....
738
739here `<path>` is the complete path of the file or subdirectory to
740be removed from the branch.
741See `filemodify` above for a detailed description of `<path>`.
742
743`filecopy`
744^^^^^^^^^^
745Recursively copies an existing file or subdirectory to a different
746location within the branch. The existing file or directory must
747exist. If the destination exists it will be completely replaced
748by the content copied from the source.
749
750....
751 'C' SP <path> SP <path> LF
752....
753
754here the first `<path>` is the source location and the second
755`<path>` is the destination. See `filemodify` above for a detailed
756description of what `<path>` may look like. To use a source path
757that contains SP the path must be quoted.
758
759A `filecopy` command takes effect immediately. Once the source
760location has been copied to the destination any future commands
761applied to the source location will not impact the destination of
762the copy.
763
764`filerename`
765^^^^^^^^^^^^
766Renames an existing file or subdirectory to a different location
767within the branch. The existing file or directory must exist. If
768the destination exists it will be replaced by the source directory.
769
770....
771 'R' SP <path> SP <path> LF
772....
773
774here the first `<path>` is the source location and the second
775`<path>` is the destination. See `filemodify` above for a detailed
776description of what `<path>` may look like. To use a source path
777that contains SP the path must be quoted.
778
779A `filerename` command takes effect immediately. Once the source
780location has been renamed to the destination any future commands
781applied to the source location will create new files there and not
782impact the destination of the rename.
783
784Note that a `filerename` is the same as a `filecopy` followed by a
785`filedelete` of the source location. There is a slight performance
786advantage to using `filerename`, but the advantage is so small
787that it is never worth trying to convert a delete/add pair in
788source material into a rename for fast-import. This `filerename`
789command is provided just to simplify frontends that already have
790rename information and don't want bother with decomposing it into a
791`filecopy` followed by a `filedelete`.
792
793`filedeleteall`
794^^^^^^^^^^^^^^^
795Included in a `commit` command to remove all files (and also all
796directories) from the branch. This command resets the internal
797branch structure to have no files in it, allowing the frontend
798to subsequently add all interesting files from scratch.
799
800....
801 'deleteall' LF
802....
803
804This command is extremely useful if the frontend does not know
805(or does not care to know) what files are currently on the branch,
806and therefore cannot generate the proper `filedelete` commands to
807update the content.
808
809Issuing a `filedeleteall` followed by the needed `filemodify`
810commands to set the correct content will produce the same results
811as sending only the needed `filemodify` and `filedelete` commands.
812The `filedeleteall` approach may however require fast-import to use slightly
813more memory per active branch (less than 1 MiB for even most large
814projects); so frontends that can easily obtain only the affected
815paths for a commit are encouraged to do so.
816
817`notemodify`
818^^^^^^^^^^^^
819Included in a `commit` `<notes-ref>` command to add a new note
820annotating a `<commit-ish>` or change this annotation contents.
821Internally it is similar to filemodify 100644 on `<commit-ish>`
822path (maybe split into subdirectories). It's not advised to
823use any other commands to write to the `<notes-ref>` tree except
824`filedeleteall` to delete all existing notes in this tree.
825This command has two different means of specifying the content
826of the note.
827
828External data format::
829 The data content for the note was already supplied by a prior
830 `blob` command. The frontend just needs to connect it to the
831 commit that is to be annotated.
832+
833....
834 'N' SP <dataref> SP <commit-ish> LF
835....
836+
837Here `<dataref>` can be either a mark reference (`:<idnum>`)
838set by a prior `blob` command, or a full 40-byte SHA-1 of an
839existing Git blob object.
840
841Inline data format::
842 The data content for the note has not been supplied yet.
843 The frontend wants to supply it as part of this modify
844 command.
845+
846....
847 'N' SP 'inline' SP <commit-ish> LF
848 data
849....
850+
851See below for a detailed description of the `data` command.
852
853In both formats `<commit-ish>` is any of the commit specification
854expressions also accepted by `from` (see above).
855
856`mark`
857~~~~~~
858Arranges for fast-import to save a reference to the current object, allowing
859the frontend to recall this object at a future point in time, without
860knowing its SHA-1. Here the current object is the object creation
861command the `mark` command appears within. This can be `commit`,
862`tag`, and `blob`, but `commit` is the most common usage.
863
864....
865 'mark' SP ':' <idnum> LF
866....
867
868where `<idnum>` is the number assigned by the frontend to this mark.
869The value of `<idnum>` is expressed as an ASCII decimal integer.
870The value 0 is reserved and cannot be used as
871a mark. Only values greater than or equal to 1 may be used as marks.
872
873New marks are created automatically. Existing marks can be moved
874to another object simply by reusing the same `<idnum>` in another
875`mark` command.
876
877`original-oid`
878~~~~~~~~~~~~~~
879Provides the name of the object in the original source control system.
880fast-import will simply ignore this directive, but filter processes
881which operate on and modify the stream before feeding to fast-import
882may have uses for this information
883
884....
885 'original-oid' SP <object-identifier> LF
886....
887
888where `<object-identifier>` is any string not containing LF.
889
890`tag`
891~~~~~
892Creates an annotated tag referring to a specific commit. To create
893lightweight (non-annotated) tags see the `reset` command below.
894
895....
896 'tag' SP <name> LF
897 mark?
898 'from' SP <commit-ish> LF
899 original-oid?
900 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
901 data
902....
903
904where `<name>` is the name of the tag to create.
905
906Tag names are automatically prefixed with `refs/tags/` when stored
907in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
908use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
909corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
910
911The value of `<name>` must be a valid refname in Git and therefore
912may contain forward slashes. As `LF` is not valid in a Git refname,
913no quoting or escaping syntax is supported here.
914
915The `from` command is the same as in the `commit` command; see
916above for details.
917
918The `tagger` command uses the same format as `committer` within
919`commit`; again see above for details.
920
921The `data` command following `tagger` must supply the annotated tag
922message (see below for `data` command syntax). To import an empty
923tag message use a 0 length data. Tag messages are free-form and are
924not interpreted by Git. Currently they must be encoded in UTF-8,
925as fast-import does not permit other encodings to be specified.
926
927Signing annotated tags during import from within fast-import is not
928supported. Trying to include your own PGP/GPG signature is not
929recommended, as the frontend does not (easily) have access to the
930complete set of bytes which normally goes into such a signature.
931If signing is required, create lightweight tags from within fast-import with
932`reset`, then create the annotated versions of those tags offline
933with the standard 'git tag' process.
934
935`reset`
936~~~~~~~
937Creates (or recreates) the named branch, optionally starting from
938a specific revision. The reset command allows a frontend to issue
939a new `from` command for an existing branch, or to create a new
940branch from an existing commit without creating a new commit.
941
942....
943 'reset' SP <ref> LF
944 ('from' SP <commit-ish> LF)?
945 LF?
946....
947
948For a detailed description of `<ref>` and `<commit-ish>` see above
949under `commit` and `from`.
950
951The `LF` after the command is optional (it used to be required).
952
953The `reset` command can also be used to create lightweight
954(non-annotated) tags. For example:
955
956====
957 reset refs/tags/938
958 from :938
959====
960
961would create the lightweight tag `refs/tags/938` referring to
962whatever commit mark `:938` references.
963
964`blob`
965~~~~~~
966Requests writing one file revision to the packfile. The revision
967is not connected to any commit; this connection must be formed in
968a subsequent `commit` command by referencing the blob through an
969assigned mark.
970
971....
972 'blob' LF
973 mark?
974 original-oid?
975 data
976....
977
978The mark command is optional here as some frontends have chosen
979to generate the Git SHA-1 for the blob on their own, and feed that
980directly to `commit`. This is typically more work than it's worth
981however, as marks are inexpensive to store and easy to use.
982
983`data`
984~~~~~~
985Supplies raw data (for use as blob/file content, commit messages, or
986annotated tag messages) to fast-import. Data can be supplied using an exact
987byte count or delimited with a terminating line. Real frontends
988intended for production-quality conversions should always use the
989exact byte count format, as it is more robust and performs better.
990The delimited format is intended primarily for testing fast-import.
991
992Comment lines appearing within the `<raw>` part of `data` commands
993are always taken to be part of the body of the data and are therefore
994never ignored by fast-import. This makes it safe to import any
995file/message content whose lines might start with `#`.
996
997Exact byte count format::
998 The frontend must specify the number of bytes of data.
999+
1000....
1001 'data' SP <count> LF
1002 <raw> LF?
1003....
1004+
1005where `<count>` is the exact number of bytes appearing within
1006`<raw>`. The value of `<count>` is expressed as an ASCII decimal
1007integer. The `LF` on either side of `<raw>` is not
1008included in `<count>` and will not be included in the imported data.
1009+
1010The `LF` after `<raw>` is optional (it used to be required) but
1011recommended. Always including it makes debugging a fast-import
1012stream easier as the next command always starts in column 0
1013of the next line, even if `<raw>` did not end with an `LF`.
1014
1015Delimited format::
1016 A delimiter string is used to mark the end of the data.
1017 fast-import will compute the length by searching for the delimiter.
1018 This format is primarily useful for testing and is not
1019 recommended for real data.
1020+
1021....
1022 'data' SP '<<' <delim> LF
1023 <raw> LF
1024 <delim> LF
1025 LF?
1026....
1027+
1028where `<delim>` is the chosen delimiter string. The string `<delim>`
1029must not appear on a line by itself within `<raw>`, as otherwise
1030fast-import will think the data ends earlier than it really does. The `LF`
1031immediately trailing `<raw>` is part of `<raw>`. This is one of
1032the limitations of the delimited format, it is impossible to supply
1033a data chunk which does not have an LF as its last byte.
1034+
1035The `LF` after `<delim> LF` is optional (it used to be required).
1036
1037`alias`
1038~~~~~~~
1039Record that a mark refers to a given object without first creating any
1040new object.
1041
1042....
1043 'alias' LF
1044 mark
1045 'to' SP <commit-ish> LF
1046 LF?
1047....
1048
1049For a detailed description of `<commit-ish>` see above under `from`.
1050
1051
1052`checkpoint`
1053~~~~~~~~~~~~
1054Forces fast-import to close the current packfile, start a new one, and to
1055save out all current branch refs, tags and marks.
1056
1057....
1058 'checkpoint' LF
1059 LF?
1060....
1061
1062Note that fast-import automatically switches packfiles when the current
1063packfile reaches --max-pack-size, or 4 GiB, whichever limit is
1064smaller. During an automatic packfile switch fast-import does not update
1065the branch refs, tags or marks.
1066
1067As a `checkpoint` can require a significant amount of CPU time and
1068disk IO (to compute the overall pack SHA-1 checksum, generate the
1069corresponding index file, and update the refs) it can easily take
1070several minutes for a single `checkpoint` command to complete.
1071
1072Frontends may choose to issue checkpoints during extremely large
1073and long running imports, or when they need to allow another Git
1074process access to a branch. However given that a 30 GiB Subversion
1075repository can be loaded into Git through fast-import in about 3 hours,
1076explicit checkpointing may not be necessary.
1077
1078The `LF` after the command is optional (it used to be required).
1079
1080`progress`
1081~~~~~~~~~~
1082Causes fast-import to print the entire `progress` line unmodified to
1083its standard output channel (file descriptor 1) when the command is
1084processed from the input stream. The command otherwise has no impact
1085on the current import, or on any of fast-import's internal state.
1086
1087....
1088 'progress' SP <any> LF
1089 LF?
1090....
1091
1092The `<any>` part of the command may contain any sequence of bytes
1093that does not contain `LF`. The `LF` after the command is optional.
1094Callers may wish to process the output through a tool such as sed to
1095remove the leading part of the line, for example:
1096
1097====
1098 frontend | git fast-import | sed 's/^progress //'
1099====
1100
1101Placing a `progress` command immediately after a `checkpoint` will
1102inform the reader when the `checkpoint` has been completed and it
1103can safely access the refs that fast-import updated.
1104
1105`get-mark`
1106~~~~~~~~~~
1107Causes fast-import to print the SHA-1 corresponding to a mark to
1108stdout or to the file descriptor previously arranged with the
1109`--cat-blob-fd` argument. The command otherwise has no impact on the
1110current import; its purpose is to retrieve SHA-1s that later commits
1111might want to refer to in their commit messages.
1112
1113....
1114 'get-mark' SP ':' <idnum> LF
1115....
1116
1117See ``Responses To Commands'' below for details about how to read
1118this output safely.
1119
1120`cat-blob`
1121~~~~~~~~~~
1122Causes fast-import to print a blob to a file descriptor previously
1123arranged with the `--cat-blob-fd` argument. The command otherwise
1124has no impact on the current import; its main purpose is to
1125retrieve blobs that may be in fast-import's memory but not
1126accessible from the target repository.
1127
1128....
1129 'cat-blob' SP <dataref> LF
1130....
1131
1132The `<dataref>` can be either a mark reference (`:<idnum>`)
1133set previously or a full 40-byte SHA-1 of a Git blob, preexisting or
1134ready to be written.
1135
1136Output uses the same format as `git cat-file --batch`:
1137
1138====
1139 <sha1> SP 'blob' SP <size> LF
1140 <contents> LF
1141====
1142
1143This command can be used where a `filemodify` directive can appear,
1144allowing it to be used in the middle of a commit. For a `filemodify`
1145using an inline directive, it can also appear right before the `data`
1146directive.
1147
1148See ``Responses To Commands'' below for details about how to read
1149this output safely.
1150
1151`ls`
1152~~~~
1153Prints information about the object at a path to a file descriptor
1154previously arranged with the `--cat-blob-fd` argument. This allows
1155printing a blob from the active commit (with `cat-blob`) or copying a
1156blob or tree from a previous commit for use in the current one (with
1157`filemodify`).
1158
1159The `ls` command can also be used where a `filemodify` directive can
1160appear, allowing it to be used in the middle of a commit.
1161
1162Reading from the active commit::
1163 This form can only be used in the middle of a `commit`.
1164 The path names a directory entry within fast-import's
1165 active commit. The path must be quoted in this case.
1166+
1167....
1168 'ls' SP <path> LF
1169....
1170
1171Reading from a named tree::
1172 The `<dataref>` can be a mark reference (`:<idnum>`) or the
1173 full 40-byte SHA-1 of a Git tag, commit, or tree object,
1174 preexisting or waiting to be written.
1175 The path is relative to the top level of the tree
1176 named by `<dataref>`.
1177+
1178....
1179 'ls' SP <dataref> SP <path> LF
1180....
1181
1182See `filemodify` above for a detailed description of `<path>`.
1183
1184Output uses the same format as `git ls-tree <tree> -- <path>`:
1185
1186====
1187 <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF
1188====
1189
1190The <dataref> represents the blob, tree, or commit object at <path>
1191and can be used in later 'get-mark', 'cat-blob', 'filemodify', or
1192'ls' commands.
1193
1194If there is no file or subtree at that path, 'git fast-import' will
1195instead report
1196
1197====
1198 missing SP <path> LF
1199====
1200
1201See ``Responses To Commands'' below for details about how to read
1202this output safely.
1203
1204`feature`
1205~~~~~~~~~
1206Require that fast-import supports the specified feature, or abort if
1207it does not.
1208
1209....
1210 'feature' SP <feature> ('=' <argument>)? LF
1211....
1212
1213The <feature> part of the command may be any one of the following:
1214
1215date-format::
1216export-marks::
1217relative-marks::
1218no-relative-marks::
1219force::
1220 Act as though the corresponding command-line option with
1221 a leading `--` was passed on the command line
1222 (see OPTIONS, above).
1223
1224import-marks::
1225import-marks-if-exists::
1226 Like --import-marks except in two respects: first, only one
1227 "feature import-marks" or "feature import-marks-if-exists"
1228 command is allowed per stream; second, an --import-marks=
1229 or --import-marks-if-exists command-line option overrides
1230 any of these "feature" commands in the stream; third,
1231 "feature import-marks-if-exists" like a corresponding
1232 command-line option silently skips a nonexistent file.
1233
1234get-mark::
1235cat-blob::
1236ls::
1237 Require that the backend support the 'get-mark', 'cat-blob',
1238 or 'ls' command respectively.
1239 Versions of fast-import not supporting the specified command
1240 will exit with a message indicating so.
1241 This lets the import error out early with a clear message,
1242 rather than wasting time on the early part of an import
1243 before the unsupported command is detected.
1244
1245notes::
1246 Require that the backend support the 'notemodify' (N)
1247 subcommand to the 'commit' command.
1248 Versions of fast-import not supporting notes will exit
1249 with a message indicating so.
1250
1251done::
1252 Error out if the stream ends without a 'done' command.
1253 Without this feature, errors causing the frontend to end
1254 abruptly at a convenient point in the stream can go
1255 undetected. This may occur, for example, if an import
1256 front end dies in mid-operation without emitting SIGTERM
1257 or SIGKILL at its subordinate git fast-import instance.
1258
1259`option`
1260~~~~~~~~
1261Processes the specified option so that git fast-import behaves in a
1262way that suits the frontend's needs.
1263Note that options specified by the frontend are overridden by any
1264options the user may specify to git fast-import itself.
1265
1266....
1267 'option' SP <option> LF
1268....
1269
1270The `<option>` part of the command may contain any of the options
1271listed in the OPTIONS section that do not change import semantics,
1272without the leading `--` and is treated in the same way.
1273
1274Option commands must be the first commands on the input (not counting
1275feature commands), to give an option command after any non-option
1276command is an error.
1277
1278The following command-line options change import semantics and may therefore
1279not be passed as option:
1280
1281* date-format
1282* import-marks
1283* export-marks
1284* cat-blob-fd
1285* force
1286
1287`done`
1288~~~~~~
1289If the `done` feature is not in use, treated as if EOF was read.
1290This can be used to tell fast-import to finish early.
1291
1292If the `--done` command-line option or `feature done` command is
1293in use, the `done` command is mandatory and marks the end of the
1294stream.
1295
1296RESPONSES TO COMMANDS
1297---------------------
1298New objects written by fast-import are not available immediately.
1299Most fast-import commands have no visible effect until the next
1300checkpoint (or completion). The frontend can send commands to
1301fill fast-import's input pipe without worrying about how quickly
1302they will take effect, which improves performance by simplifying
1303scheduling.
1304
1305For some frontends, though, it is useful to be able to read back
1306data from the current repository as it is being updated (for
1307example when the source material describes objects in terms of
1308patches to be applied to previously imported objects). This can
1309be accomplished by connecting the frontend and fast-import via
1310bidirectional pipes:
1311
1312====
1313 mkfifo fast-import-output
1314 frontend <fast-import-output |
1315 git fast-import >fast-import-output
1316====
1317
1318A frontend set up this way can use `progress`, `get-mark`, `ls`, and
1319`cat-blob` commands to read information from the import in progress.
1320
1321To avoid deadlock, such frontends must completely consume any
1322pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before
1323performing writes to fast-import that might block.
1324
1325CRASH REPORTS
1326-------------
1327If fast-import is supplied invalid input it will terminate with a
1328non-zero exit status and create a crash report in the top level of
1329the Git repository it was importing into. Crash reports contain
1330a snapshot of the internal fast-import state as well as the most
1331recent commands that lead up to the crash.
1332
1333All recent commands (including stream comments, file changes and
1334progress commands) are shown in the command history within the crash
1335report, but raw file data and commit messages are excluded from the
1336crash report. This exclusion saves space within the report file
1337and reduces the amount of buffering that fast-import must perform
1338during execution.
1339
1340After writing a crash report fast-import will close the current
1341packfile and export the marks table. This allows the frontend
1342developer to inspect the repository state and resume the import from
1343the point where it crashed. The modified branches and tags are not
1344updated during a crash, as the import did not complete successfully.
1345Branch and tag information can be found in the crash report and
1346must be applied manually if the update is needed.
1347
1348An example crash:
1349
1350====
1351 $ cat >in <<END_OF_INPUT
1352 # my very first test commit
1353 commit refs/heads/master
1354 committer Shawn O. Pearce <spearce> 19283 -0400
1355 # who is that guy anyway?
1356 data <<EOF
1357 this is my commit
1358 EOF
1359 M 644 inline .gitignore
1360 data <<EOF
1361 .gitignore
1362 EOF
1363 M 777 inline bob
1364 END_OF_INPUT
1365
1366 $ git fast-import <in
1367 fatal: Corrupt mode: M 777 inline bob
1368 fast-import: dumping crash report to .git/fast_import_crash_8434
1369
1370 $ cat .git/fast_import_crash_8434
1371 fast-import crash report:
1372 fast-import process: 8434
1373 parent process : 1391
1374 at Sat Sep 1 00:58:12 2007
1375
1376 fatal: Corrupt mode: M 777 inline bob
1377
1378 Most Recent Commands Before Crash
1379 ---------------------------------
1380 # my very first test commit
1381 commit refs/heads/master
1382 committer Shawn O. Pearce <spearce> 19283 -0400
1383 # who is that guy anyway?
1384 data <<EOF
1385 M 644 inline .gitignore
1386 data <<EOF
1387 * M 777 inline bob
1388
1389 Active Branch LRU
1390 -----------------
1391 active_branches = 1 cur, 5 max
1392
1393 pos clock name
1394 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1395 1) 0 refs/heads/master
1396
1397 Inactive Branches
1398 -----------------
1399 refs/heads/master:
1400 status : active loaded dirty
1401 tip commit : 0000000000000000000000000000000000000000
1402 old tree : 0000000000000000000000000000000000000000
1403 cur tree : 0000000000000000000000000000000000000000
1404 commit clock: 0
1405 last pack :
1406
1407
1408 -------------------
1409 END OF CRASH REPORT
1410====
1411
1412TIPS AND TRICKS
1413---------------
1414The following tips and tricks have been collected from various
1415users of fast-import, and are offered here as suggestions.
1416
1417Use One Mark Per Commit
1418~~~~~~~~~~~~~~~~~~~~~~~
1419When doing a repository conversion, use a unique mark per commit
1420(`mark :<n>`) and supply the --export-marks option on the command
1421line. fast-import will dump a file which lists every mark and the Git
1422object SHA-1 that corresponds to it. If the frontend can tie
1423the marks back to the source repository, it is easy to verify the
1424accuracy and completeness of the import by comparing each Git
1425commit to the corresponding source revision.
1426
1427Coming from a system such as Perforce or Subversion, this should be
1428quite simple, as the fast-import mark can also be the Perforce changeset
1429number or the Subversion revision number.
1430
1431Freely Skip Around Branches
1432~~~~~~~~~~~~~~~~~~~~~~~~~~~
1433Don't bother trying to optimize the frontend to stick to one branch
1434at a time during an import. Although doing so might be slightly
1435faster for fast-import, it tends to increase the complexity of the frontend
1436code considerably.
1437
1438The branch LRU builtin to fast-import tends to behave very well, and the
1439cost of activating an inactive branch is so low that bouncing around
1440between branches has virtually no impact on import performance.
1441
1442Handling Renames
1443~~~~~~~~~~~~~~~~
1444When importing a renamed file or directory, simply delete the old
1445name(s) and modify the new name(s) during the corresponding commit.
1446Git performs rename detection after-the-fact, rather than explicitly
1447during a commit.
1448
1449Use Tag Fixup Branches
1450~~~~~~~~~~~~~~~~~~~~~~
1451Some other SCM systems let the user create a tag from multiple
1452files which are not from the same commit/changeset. Or to create
1453tags which are a subset of the files available in the repository.
1454
1455Importing these tags as-is in Git is impossible without making at
1456least one commit which ``fixes up'' the files to match the content
1457of the tag. Use fast-import's `reset` command to reset a dummy branch
1458outside of your normal branch space to the base commit for the tag,
1459then commit one or more file fixup commits, and finally tag the
1460dummy branch.
1461
1462For example since all normal branches are stored under `refs/heads/`
1463name the tag fixup branch `TAG_FIXUP`. This way it is impossible for
1464the fixup branch used by the importer to have namespace conflicts
1465with real branches imported from the source (the name `TAG_FIXUP`
1466is not `refs/heads/TAG_FIXUP`).
1467
1468When committing fixups, consider using `merge` to connect the
1469commit(s) which are supplying file revisions to the fixup branch.
1470Doing so will allow tools such as 'git blame' to track
1471through the real commit history and properly annotate the source
1472files.
1473
1474After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP`
1475to remove the dummy branch.
1476
1477Import Now, Repack Later
1478~~~~~~~~~~~~~~~~~~~~~~~~
1479As soon as fast-import completes the Git repository is completely valid
1480and ready for use. Typically this takes only a very short time,
1481even for considerably large projects (100,000+ commits).
1482
1483However repacking the repository is necessary to improve data
1484locality and access performance. It can also take hours on extremely
1485large projects (especially if -f and a large --window parameter is
1486used). Since repacking is safe to run alongside readers and writers,
1487run the repack in the background and let it finish when it finishes.
1488There is no reason to wait to explore your new Git project!
1489
1490If you choose to wait for the repack, don't try to run benchmarks
1491or performance tests until repacking is completed. fast-import outputs
1492suboptimal packfiles that are simply never seen in real use
1493situations.
1494
1495Repacking Historical Data
1496~~~~~~~~~~~~~~~~~~~~~~~~~
1497If you are repacking very old imported data (e.g. older than the
1498last year), consider expending some extra CPU time and supplying
1499--window=50 (or higher) when you run 'git repack'.
1500This will take longer, but will also produce a smaller packfile.
1501You only need to expend the effort once, and everyone using your
1502project will benefit from the smaller repository.
1503
1504Include Some Progress Messages
1505~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1506Every once in a while have your frontend emit a `progress` message
1507to fast-import. The contents of the messages are entirely free-form,
1508so one suggestion would be to output the current month and year
1509each time the current commit date moves into the next month.
1510Your users will feel better knowing how much of the data stream
1511has been processed.
1512
1513
1514PACKFILE OPTIMIZATION
1515---------------------
1516When packing a blob fast-import always attempts to deltify against the last
1517blob written. Unless specifically arranged for by the frontend,
1518this will probably not be a prior version of the same file, so the
1519generated delta will not be the smallest possible. The resulting
1520packfile will be compressed, but will not be optimal.
1521
1522Frontends which have efficient access to all revisions of a
1523single file (for example reading an RCS/CVS ,v file) can choose
1524to supply all revisions of that file as a sequence of consecutive
1525`blob` commands. This allows fast-import to deltify the different file
1526revisions against each other, saving space in the final packfile.
1527Marks can be used to later identify individual file revisions during
1528a sequence of `commit` commands.
1529
1530The packfile(s) created by fast-import do not encourage good disk access
1531patterns. This is caused by fast-import writing the data in the order
1532it is received on standard input, while Git typically organizes
1533data within packfiles to make the most recent (current tip) data
1534appear before historical data. Git also clusters commits together,
1535speeding up revision traversal through better cache locality.
1536
1537For this reason it is strongly recommended that users repack the
1538repository with `git repack -a -d` after fast-import completes, allowing
1539Git to reorganize the packfiles for faster data access. If blob
1540deltas are suboptimal (see above) then also adding the `-f` option
1541to force recomputation of all deltas can significantly reduce the
1542final packfile size (30-50% smaller can be quite typical).
1543
1544Instead of running `git repack` you can also run `git gc
1545--aggressive`, which will also optimize other things after an import
1546(e.g. pack loose refs). As noted in the "AGGRESSIVE" section in
1547linkgit:git-gc[1] the `--aggressive` option will find new deltas with
1548the `-f` option to linkgit:git-repack[1]. For the reasons elaborated
1549on above using `--aggressive` after a fast-import is one of the few
1550cases where it's known to be worthwhile.
1551
1552MEMORY UTILIZATION
1553------------------
1554There are a number of factors which affect how much memory fast-import
1555requires to perform an import. Like critical sections of core
1556Git, fast-import uses its own memory allocators to amortize any overheads
1557associated with malloc. In practice fast-import tends to amortize any
1558malloc overheads to 0, due to its use of large block allocations.
1559
1560per object
1561~~~~~~~~~~
1562fast-import maintains an in-memory structure for every object written in
1563this execution. On a 32 bit system the structure is 32 bytes,
1564on a 64 bit system the structure is 40 bytes (due to the larger
1565pointer sizes). Objects in the table are not deallocated until
1566fast-import terminates. Importing 2 million objects on a 32 bit system
1567will require approximately 64 MiB of memory.
1568
1569The object table is actually a hashtable keyed on the object name
1570(the unique SHA-1). This storage configuration allows fast-import to reuse
1571an existing or already written object and avoid writing duplicates
1572to the output packfile. Duplicate blobs are surprisingly common
1573in an import, typically due to branch merges in the source.
1574
1575per mark
1576~~~~~~~~
1577Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
1578bytes, depending on pointer size) per mark. Although the array
1579is sparse, frontends are still strongly encouraged to use marks
1580between 1 and n, where n is the total number of marks required for
1581this import.
1582
1583per branch
1584~~~~~~~~~~
1585Branches are classified as active and inactive. The memory usage
1586of the two classes is significantly different.
1587
1588Inactive branches are stored in a structure which uses 96 or 120
1589bytes (32 bit or 64 bit systems, respectively), plus the length of
1590the branch name (typically under 200 bytes), per branch. fast-import will
1591easily handle as many as 10,000 inactive branches in under 2 MiB
1592of memory.
1593
1594Active branches have the same overhead as inactive branches, but
1595also contain copies of every tree that has been recently modified on
1596that branch. If subtree `include` has not been modified since the
1597branch became active, its contents will not be loaded into memory,
1598but if subtree `src` has been modified by a commit since the branch
1599became active, then its contents will be loaded in memory.
1600
1601As active branches store metadata about the files contained on that
1602branch, their in-memory storage size can grow to a considerable size
1603(see below).
1604
1605fast-import automatically moves active branches to inactive status based on
1606a simple least-recently-used algorithm. The LRU chain is updated on
1607each `commit` command. The maximum number of active branches can be
1608increased or decreased on the command line with --active-branches=.
1609
1610per active tree
1611~~~~~~~~~~~~~~~
1612Trees (aka directories) use just 12 bytes of memory on top of the
1613memory required for their entries (see ``per active file'' below).
1614The cost of a tree is virtually 0, as its overhead amortizes out
1615over the individual file entries.
1616
1617per active file entry
1618~~~~~~~~~~~~~~~~~~~~~
1619Files (and pointers to subtrees) within active trees require 52 or 64
1620bytes (32/64 bit platforms) per entry. To conserve space, file and
1621tree names are pooled in a common string table, allowing the filename
1622``Makefile'' to use just 16 bytes (after including the string header
1623overhead) no matter how many times it occurs within the project.
1624
1625The active branch LRU, when coupled with the filename string pool
1626and lazy loading of subtrees, allows fast-import to efficiently import
1627projects with 2,000+ branches and 45,114+ files in a very limited
1628memory footprint (less than 2.7 MiB per active branch).
1629
1630SIGNALS
1631-------
1632Sending *SIGUSR1* to the 'git fast-import' process ends the current
1633packfile early, simulating a `checkpoint` command. The impatient
1634operator can use this facility to peek at the objects and refs from an
1635import in progress, at the cost of some added running time and worse
1636compression.
1637
1638CONFIGURATION
1639-------------
1640
1641include::includes/cmd-config-section-all.adoc[]
1642
1643include::config/fastimport.adoc[]
1644
1645SEE ALSO
1646--------
1647linkgit:git-fast-export[1]
1648
1649GIT
1650---
1651Part of the linkgit:git[1] suite