git-fast-export(1)
==================

NAME
----
git-fast-export - Git data exporter


SYNOPSIS
--------
[verse]
'git fast-export' [<options>] | 'git fast-import'

DESCRIPTION
-----------
This program dumps the given revisions in a form suitable to be piped
into 'git fast-import'.

You can use it as a human-readable bundle replacement (see
linkgit:git-bundle[1]), or as a format that can be edited before being
fed to 'git fast-import' in order to do history rewrites (an ability
relied on by tools like 'git filter-repo').

OPTIONS
-------
--progress=<n>::
	Insert 'progress' statements every <n> objects, to be shown by
	'git fast-import' during import.

--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)::
	Specify how to handle signed tags.  Since any transformation
	after the export (or during the export, such as excluding
	revisions) can change the hashes being signed, the signatures
	may become invalid.
+
When asking to 'abort' (which is the default), this program will die
when encountering a signed tag.  With 'strip', the tags will silently
be made unsigned, with 'warn-strip' they will be made unsigned but a
warning will be displayed, with 'verbatim', they will be silently
exported and with 'warn-verbatim' (or 'warn', a deprecated synonym),
they will be exported, but you will see a warning.  'verbatim' and
'warn-verbatim' should only be used if you know that no transformation
affecting tags or any commit in their history will be performed by you
or by fast-export or fast-import, or if you do not care that the
resulting tag will have an invalid signature.

--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)::
	Specify how to handle signed commits.  Behaves exactly as
	'--signed-tags', but for commits.  Default is 'strip', which
	is the same as how earlier versions of this command without
	this option behaved.
+
NOTE: This is highly experimental and the format of the data stream may
change in the future without compatibility guarantees.

--tag-of-filtered-object=(abort|drop|rewrite)::
	Specify how to handle tags whose tagged object is filtered out.
	Since revisions and files to export can be limited by path,
	tagged objects may be filtered completely.
+
When asking to 'abort' (which is the default), this program will die
when encountering such a tag.  With 'drop' it will omit such tags from
the output.  With 'rewrite', if the tagged object is a commit, it will
rewrite the tag to tag an ancestor commit (via parent rewriting; see
linkgit:git-rev-list[1]).

-M::
-C::
	Perform move and/or copy detection, as described in the
	linkgit:git-diff[1] manual page, and use it to generate
	rename and copy commands in the output dump.
+
Note that earlier versions of this command did not complain and
produced incorrect results if you gave these options.

--export-marks=<file>::
	Dumps the internal marks table to <file> when complete.
	Marks are written one per line as `:markid SHA-1`. Only marks
	for revisions are dumped; marks for blobs are 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