there is no `done` command at the end of
the stream. This option might be useful for detecting errors
that cause the frontend to terminate before it has started to
write a stream.
Locations of Marks Files
~~~~~~~~~~~~~~~~~~~~~~~~
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
Frontends can use this file to validate imports after they
have been completed, or to save the marks table across
incremental runs. As <file> is only opened and truncated
at checkpoint (or completion) the same path can also be
safely given to --import-marks.
--import-marks=<file>::
Before processing any input, load the marks specified in
<file>. The input file must exist, must be readable, and
must use the same format as produced by --export-marks.
Multiple options may be supplied to import more than one
set of marks. If a mark is defined to different values,
the last file wins.
--import-marks-if-exists=<file>::
Like --import-marks but instead of erroring out, silently
skips the file if it does not exist.
--[no-]relative-marks::
After specifying --relative-marks the paths specified
with --import-marks= and --export-marks= are relative
to an internal directory in the current repository.
In git-fast-import this means that the paths are relative
to the .git/info/fast-import directory. However, other
importers may use a different location.
+
Relative and non-relative marks may be combined by interweaving
--(no-)-relative-marks with the --(import|export)-marks= options.
Submodule Rewriting
~~~~~~~~~~~~~~~~~~~
--rewrite-submodules-from=<name>:<file>::
--rewrite-submodules-to=<name>:<file>::
Rewrite the object IDs for the submodule specified by <name> from the values
used in the from <file> to those used in the to <file>. The from marks should
have been created by `git fast-export`, and the to marks should have been
created by `git fast-import` when importing that same submodule.
+
<name> may be any arbitrary string not containing a colon character, but the
same value must be used with both options when specifying corresponding marks.
Multiple submodules may be specified with different values for <name>. It is an
error not to use these options in corresponding pairs.
+
These options are primarily useful when converting a repository from one hash
algorithm to another; without them, fast-import will fail if it encounters a
submodule because it has no way of writing the object ID into the new hash
algorithm.
Performance and Compression Tuning
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--active-branches=<n>::
Maximum number of branches to maintain active at once.
See ``Memory Utilization'' below for details. Default is 5.
--big-file-threshold=<n>::
Maximum size of a blob that fast-import will attempt to
create a delta for, expressed in bytes. The default is 512m
(512 MiB). Some importers may wish to lower this on systems
with constrained memory.
--depth=<n>::
Maximum delta depth, for blob and tree deltification.
Default is 50.
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
<file> listing the filename of the packfile and the last
commit on each branch that was written to that packfile.
This information may be useful after importing projects
whose total object set exceeds the 4 GiB packfile limit,
as these commits can be used as edge points during calls
to 'git pack-objects'.
--max-pack-size=<n>::
Maximum size of each output packfile.
The default is unlimited.
fastimport.unpackLimit::
See linkgit:git-config[1]
PERFORMANCE
-----------
The design of fast-import allows it to import large projects in a minimum
amount of memory usage and processing time. Assuming the frontend
is able to keep up with fast-import and feed it a constant stream of data,
import times for projects holding 10+ years of history and containing
100,000+ individual commits are generally completed in just 1-2
hours on quite modest