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