LF?
....

For a detailed description of `<ref>` and `<commit-ish>` see above
under `commit` and `from`.

The `LF` after the command is optional (it used to be required).

The `reset` command can also be used to create lightweight
(non-annotated) tags.  For example:

====
	reset refs/tags/938
	from :938
====

would create the lightweight tag `refs/tags/938` referring to
whatever commit mark `:938` references.

`blob`
~~~~~~
Requests writing one file revision to the packfile.  The revision
is not connected to any commit; this connection must be formed in
a subsequent `commit` command by referencing the blob through an
assigned mark.

....
	'blob' LF
	mark?
	original-oid?
	data
....

The mark command is optional here as some frontends have chosen
to generate the Git SHA-1 for the blob on their own, and feed that
directly to `commit`.  This is typically more work than it's worth
however, as marks are inexpensive to store and easy to use.

`data`
~~~~~~
Supplies raw data (for use as blob/file content, commit messages, or
annotated tag messages) to fast-import.  Data can be supplied using an exact
byte count or delimited with a terminating line.  Real frontends
intended for production-quality conversions should always use the
exact byte count format, as it is more robust and performs better.
The delimited format is intended primarily for testing fast-import.

Comment lines appearing within the `<raw>` part of `data` commands
are always taken to be part of the body of the data and are therefore
never ignored by fast-import.  This makes it safe to import any
file/message content whose lines might start with `#`.

Exact byte count format::
	The frontend must specify the number of bytes of data.
+
....
	'data' SP <count> LF
	<raw> LF?
....
+
where `<count>` is the exact number of bytes appearing within
`<raw>`.  The value of `<count>` is expressed as an ASCII decimal
integer.  The `LF` on either side of `<raw>` is not
included in `<count>` and will not be included in the imported data.
+
The `LF` after `<raw>` is optional (it used to be required) but
recommended.  Always including it makes debugging a fast-import
stream easier as the next command always starts in column 0
of the next line, even if `<raw>` did not end with an `LF`.

Delimited format::
	A delimiter string is used to mark the end of the data.
	fast-import will compute the length by searching for the delimiter.
	This format is primarily useful for testing and is not
	recommended for real data.
+
....
	'data' SP '<<' <delim> LF
	<raw> LF
	<delim> LF
	LF?
....
+
where `<delim>` is the chosen delimiter string.  The string `<delim>`
must not appear on a line by itself within `<raw>`, as otherwise
fast-import will think the data ends earlier than it really does.  The `LF`
immediately trailing `<raw>` is part of `<raw>`.  This is one of
the limitations of the delimited format, it is impossible to supply
a data chunk which does not have an LF as its last byte.
+
The `LF` after `<delim> LF` is optional (it used to be required).

`alias`
~~~~~~~
Record that a mark refers to a given object without first creating any
new object.

....
	'alias' LF
	mark
	'to' SP <commit-ish> LF
	LF?
....

For a detailed description of `<commit-ish>` see above under `from`.


`checkpoint`
~~~~~~~~~~~~
Forces fast-import to close the current packfile, start a new one, and to
save out all current branch refs, tags and marks.

....
	'checkpoint' LF
	LF?
....

Note that fast-import automatically switches packfiles when the current
packfile reaches --max-pack-size, or 4 GiB, whichever limit is
smaller.  During an automatic packfile switch fast-import does not update
the branch refs, tags or marks.

As a `checkpoint` can require a significant amount of CPU time and
disk IO (to compute the overall pack SHA-1 checksum, generate the
corresponding index file, and update the refs) it can easily take
several minutes for a single `checkpoint` command to complete.

Frontends may choose to issue checkpoints during extremely