ignored.
	Backends 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 completion, the same path can also be safely given to
	--import-marks.
	The file will not be written if no new object has been
	marked/exported.

--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.

--mark-tags::
	In addition to labelling blobs and commits with mark ids, also
	label tags.  This is useful in conjunction with
	`--export-marks` and `--import-marks`, and is also useful (and
	necessary) for exporting of nested tags.  It does not hurt
	other cases and would be the default, but many fast-import
	frontends are not prepared to accept tags with mark
	identifiers.
+
Any commits (or tags) that have already been marked will not be
exported again.  If the backend uses a similar --import-marks file,
this allows for incremental bidirectional exporting of the repository
by keeping the marks the same across runs.

--fake-missing-tagger::
	Some old repositories have tags without a tagger.  The
	fast-import protocol was pretty strict about that, and did not
	allow that.  So fake a tagger to be able to fast-import the
	output.

--use-done-feature::
	Start the stream with a 'feature done' stanza, and terminate
	it with a 'done' command.

--no-data::
	Skip output of blob objects and instead refer to blobs via
	their original SHA-1 hash.  This is useful when rewriting the
	directory structure or history of a repository without
	touching the contents of individual files.  Note that the
	resulting stream can only be used by a repository which
	already contains the necessary objects.

--full-tree::
	This option will cause fast-export to issue a "deleteall"
	directive for each commit followed by a full list of all files
	in the commit (as opposed to just listing the files which are
	different from the commit's first parent).

--anonymize::
	Anonymize the contents of the repository while still retaining
	the shape of the history and stored tree.  See the section on
	`ANONYMIZING` below.

--anonymize-map=<from>[:<to>]::
	Convert token `<from>` to `<to>` in the anonymized output. If
	`<to>` is omitted, map `<from>` to itself (i.e., do not
	anonymize it). See the section on `ANONYMIZING` below.

--reference-excluded-parents::
	By default, running a command such as `git fast-export
	master~5..master` will not include the commit master{tilde}5
	and will make master{tilde}4 no longer have master{tilde}5 as
	a parent (though both the old master{tilde}4 and new
	master{tilde}4 will have all the same files).  Use
	--reference-excluded-parents to instead have the stream
	refer to commits in the excluded range of history by their
	sha1sum.  Note that the resulting stream can only be used by a
	repository which already contains the necessary parent
	commits.

--show-original-ids::
	Add an extra directive to the output for commits and blobs,
	`original-oid <SHA1SUM>`.  While such directives will likely be
	ignored by importers such as git-fast-import, it may be useful
	for intermediary filters (e.g. for rewriting commit messages
	which refer to older commits, or for stripping blobs by id).

--reencode=(yes|no|abort)::
	Specify how to handle `encoding` header in commit objects.  When
	asking to 'abort' (which is the default), this program will die
	when encountering such a commit object.  With 'yes', the commit
	message will be re-encoded into UTF-8.  With 'no', the original
	encoding will be preserved.

--refspec::
	Apply the specified refspec to each ref exported. Multiple of them can
	be specified.

[<git-rev-list-args>...]::
	A list of arguments, acceptable to 'git rev-parse' and
	'git rev-list', that specifies the specific objects and references
	to export.  For example, `master~10..master` causes the
	current master reference