the destination of the rename.

Note that a `filerename` is the same as a `filecopy` followed by a
`filedelete` of the source location.  There is a slight performance
advantage to using `filerename`, but the advantage is so small
that it is never worth trying to convert a delete/add pair in
source material into a rename for fast-import.  This `filerename`
command is provided just to simplify frontends that already have
rename information and don't want bother with decomposing it into a
`filecopy` followed by a `filedelete`.

`filedeleteall`
^^^^^^^^^^^^^^^
Included in a `commit` command to remove all files (and also all
directories) from the branch.  This command resets the internal
branch structure to have no files in it, allowing the frontend
to subsequently add all interesting files from scratch.

....
	'deleteall' LF
....

This command is extremely useful if the frontend does not know
(or does not care to know) what files are currently on the branch,
and therefore cannot generate the proper `filedelete` commands to
update the content.

Issuing a `filedeleteall` followed by the needed `filemodify`
commands to set the correct content will produce the same results
as sending only the needed `filemodify` and `filedelete` commands.
The `filedeleteall` approach may however require fast-import to use slightly
more memory per active branch (less than 1 MiB for even most large
projects); so frontends that can easily obtain only the affected
paths for a commit are encouraged to do so.

`notemodify`
^^^^^^^^^^^^
Included in a `commit` `<notes-ref>` command to add a new note
annotating a `<commit-ish>` or change this annotation contents.
Internally it is similar to filemodify 100644 on `<commit-ish>`
path (maybe split into subdirectories). It's not advised to
use any other commands to write to the `<notes-ref>` tree except
`filedeleteall` to delete all existing notes in this tree.
This command has two different means of specifying the content
of the note.

External data format::
	The data content for the note was already supplied by a prior
	`blob` command.  The frontend just needs to connect it to the
	commit that is to be annotated.
+
....
	'N' SP <dataref> SP <commit-ish> LF
....
+
Here `<dataref>` can be either a mark reference (`:<idnum>`)
set by a prior `blob` command, or a full 40-byte SHA-1 of an
existing Git blob object.

Inline data format::
	The data content for the note has not been supplied yet.
	The frontend wants to supply it as part of this modify
	command.
+
....
	'N' SP 'inline' SP <commit-ish> LF
	data
....
+
See below for a detailed description of the `data` command.

In both formats `<commit-ish>` is any of the commit specification
expressions also accepted by `from` (see above).

`mark`
~~~~~~
Arranges for fast-import to save a reference to the current object, allowing
the frontend to recall this object at a future point in time, without
knowing its SHA-1.  Here the current object is the object creation
command the `mark` command appears within.  This can be `commit`,
`tag`, and `blob`, but `commit` is the most common usage.

....
	'mark' SP ':' <idnum> LF
....

where `<idnum>` is the number assigned by the frontend to this mark.
The value of `<idnum>` is expressed as an ASCII decimal integer.
The value 0 is reserved and cannot be used as
a mark.  Only values greater than or equal to 1 may be used as marks.

New marks are created automatically.  Existing marks can be moved
to another object simply by reusing the same `<idnum>` in another
`mark` command.

`original-oid`
~~~~~~~~~~~~~~
Provides the name of the object in the original source control system.
fast-import will simply ignore this directive, but filter processes
which operate on and modify the stream before feeding to fast-import
may have uses for this information

....
	'original-oid' SP <object-identifier> LF
....

where `<object-identifier>` is any string not containing LF.

`tag`
~~~~~
Creates an annotated tag referring to a specific commit.  To create