support the 'get-mark', 'cat-blob',
	or 'ls' command respectively.
	Versions of fast-import not supporting the specified command
	will exit with a message indicating so.
	This lets the import error out early with a clear message,
	rather than wasting time on the early part of an import
	before the unsupported command is detected.

notes::
	Require that the backend support the 'notemodify' (N)
	subcommand to the 'commit' command.
	Versions of fast-import not supporting notes will exit
	with a message indicating so.

done::
	Error out if the stream ends without a 'done' command.
	Without this feature, errors causing the frontend to end
	abruptly at a convenient point in the stream can go
	undetected.  This may occur, for example, if an import
	front end dies in mid-operation without emitting SIGTERM
	or SIGKILL at its subordinate git fast-import instance.

`option`
~~~~~~~~
Processes the specified option so that git fast-import behaves in a
way that suits the frontend's needs.
Note that options specified by the frontend are overridden by any
options the user may specify to git fast-import itself.

....
    'option' SP <option> LF
....

The `<option>` part of the command may contain any of the options
listed in the OPTIONS section that do not change import semantics,
without the leading `--` and is treated in the same way.

Option commands must be the first commands on the input (not counting
feature commands), to give an option command after any non-option
command is an error.

The following command-line options change import semantics and may therefore
not be passed as option:

* date-format
* import-marks
* export-marks
* cat-blob-fd
* force

`done`
~~~~~~
If the `done` feature is not in use, treated as if EOF was read.
This can be used to tell fast-import to finish early.

If the `--done` command-line option or `feature done` command is
in use, the `done` command is mandatory and marks the end of the
stream.

RESPONSES TO COMMANDS
---------------------
New objects written by fast-import are not available immediately.
Most fast-import commands have no visible effect until the next
checkpoint (or completion).  The frontend can send commands to
fill fast-import's input pipe without worrying about how quickly
they will take effect, which improves performance by simplifying
scheduling.

For some frontends, though, it is useful to be able to read back
data from the current repository as it is being updated (for
example when the source material describes objects in terms of
patches to be applied to previously imported objects).  This can
be accomplished by connecting the frontend and fast-import via
bidirectional pipes:

====
	mkfifo fast-import-output
	frontend <fast-import-output |
	git fast-import >fast-import-output
====

A frontend set up this way can use `progress`, `get-mark`, `ls`, and
`cat-blob` commands to read information from the import in progress.

To avoid deadlock, such frontends must completely consume any
pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before
performing writes to fast-import that might block.

CRASH REPORTS
-------------
If fast-import is supplied invalid input it will terminate with a
non-zero exit status and create a crash report in the top level of
the Git repository it was importing into.  Crash reports contain
a snapshot of the internal fast-import state as well as the most
recent commands that lead up to the crash.

All recent commands (including stream comments, file changes and
progress commands) are shown in the command history within the crash
report, but raw file data and commit messages are excluded from the
crash report.  This exclusion saves space within the report file
and reduces the amount of buffering that fast-import must perform
during execution.

After writing a crash report fast-import will close the current
packfile and export the marks table.  This allows the frontend
developer to inspect the repository state and resume the import from
the point where it crashed.