PGP/GPG signature
that signs the commit data.

Here <alg> specifies which hashing algorithm is used for this
signature, either `sha1` or `sha256`.

NOTE: This is highly experimental and the format of the data stream may
change in the future without compatibility guarantees.

`encoding`
^^^^^^^^^^
The optional `encoding` command indicates the encoding of the commit
message.  Most commits are UTF-8 and the encoding is omitted, but this
allows importing commit messages into git without first reencoding them.

`from`
^^^^^^
The `from` command is used to specify the commit to initialize
this branch from.  This revision will be the first ancestor of the
new commit.  The state of the tree built at this commit will begin
with the state at the `from` commit, and be altered by the content
modifications in this commit.

Omitting the `from` command in the first commit of a new branch
will cause fast-import to create that commit with no ancestor. This
tends to be desired only for the initial commit of a project.
If the frontend creates all files from scratch when making a new
branch, a `merge` command may be used instead of `from` to start
the commit with an empty tree.
Omitting the `from` command on existing branches is usually desired,
as the current commit on that branch is automatically assumed to
be the first ancestor of the new commit.

As `LF` is not valid in a Git refname or SHA-1 expression, no
quoting or escaping syntax is supported within `<commit-ish>`.

Here `<commit-ish>` is any of the following:

* The name of an existing branch already in fast-import's internal branch
  table.  If fast-import doesn't know the name, it's treated as a SHA-1
  expression.

* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
+
The reason fast-import uses `:` to denote a mark reference is this character
is not legal in a Git branch name.  The leading `:` makes it easy
to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
or `refs/heads/42`), or an abbreviated SHA-1 which happened to
consist only of base-10 digits.
+
Marks must be declared (via `mark`) before they can be used.

* A complete 40 byte or abbreviated commit SHA-1 in hex.

* Any valid Git SHA-1 expression that resolves to a commit.  See
  ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.

* The special null SHA-1 (40 zeros) specifies that the branch is to be
  removed.

The special case of restarting an incremental import from the
current branch value should be written as:
----
	from refs/heads/branch^0
----
The `^0` suffix is necessary as fast-import does not permit a branch to
start from itself, and the branch is created in memory before the
`from` command is even read from the input.  Adding `^0` will force
fast-import to resolve the commit through Git's revision parsing library,
rather than its internal branch table, thereby loading in the
existing value of the branch.

`merge`
^^^^^^^
Includes one additional ancestor commit.  The additional ancestry
link does not change the way the tree state is built at this commit.
If the `from` command is
omitted when creating a new branch, the first `merge` commit will be
the first ancestor of the current commit, and the branch will start
out with no files.  An unlimited number of `merge` commands per
commit are permitted by fast-import, thereby establishing an n-way merge.

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

`filemodify`
^^^^^^^^^^^^
Included in a `commit` command to add a new file or change the
content of an existing file.  This command has two different means
of specifying the content of the file.

External data format::
	The data content for the file was already supplied by a prior
	`blob` command.  The frontend just needs to connect it.
+
....
	'M' SP <mode> SP <dataref> SP <path> LF
....
+
Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
set by a prior `blob` command, or a full 40-byte SHA-1 of an
existing