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