case a reasonable offset from UTC could be assumed.
+
Unlike the `rfc2822` format, this format is very strict.  Any
variation in formatting will cause fast-import to reject the value,
and some sanity checks on the numeric values may also be performed.

`raw-permissive`::
	This is the same as `raw` except that no sanity checks on
	the numeric epoch and local offset are performed.  This can
	be useful when trying to filter or import an existing history
	with e.g. bogus timezone values.

`rfc2822`::
	This is the standard date format as described by RFC 2822.
+
An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
parser is accurate, but a little on the lenient side.  It is the
same parser used by 'git am' when applying patches
received from email.
+
Some malformed strings may be accepted as valid dates.  In some of
these cases Git will still be able to obtain the correct date from
the malformed string.  There are also some types of malformed
strings which Git will parse wrong, and yet consider valid.
Seriously malformed strings will be rejected.
+
Unlike the `raw` format above, the time zone/UTC offset information
contained in an RFC 2822 date string is used to adjust the date
value to UTC prior to storage.  Therefore it is important that
this information be as accurate as possible.
+
If the source material uses RFC 2822 style dates,
the frontend should let fast-import handle the parsing and conversion
(rather than attempting to do it itself) as the Git parser has
been well tested in the wild.
+
Frontends should prefer the `raw` format if the source material
already uses UNIX-epoch format, can be coaxed to give dates in that
format, or its format is easily convertible to it, as there is no
ambiguity in parsing.

`now`::
	Always use the current time and time zone.  The literal
	`now` must always be supplied for `<when>`.
+
This is a toy format.  The current time and time zone of this system
is always copied into the identity string at the time it is being
created by fast-import.  There is no way to specify a different time or
time zone.
+
This particular format is supplied as it's short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
'git update-index'.
+
If separate `author` and `committer` commands are used in a `commit`
the timestamps may not match, as the system clock will be polled
twice (once for each command).  The only way to ensure that both
author and committer identity information has the same timestamp
is to omit `author` (thus copying from `committer`) or to use a
date format other than `now`.

Commands
~~~~~~~~
fast-import accepts several commands to update the current repository
and control the current import process.  More detailed discussion
(with examples) of each command follows later.

`commit`::
	Creates a new branch or updates an existing branch by
	creating a new commit and updating the branch to point at
	the newly created commit.

`tag`::
	Creates an annotated tag object from an existing commit or
	branch.  Lightweight tags are not supported by this command,
	as they are not recommended for recording meaningful points
	in time.

`reset`::
	Reset an existing branch (or a new branch) to a specific
	revision.  This command must be used to change a branch to
	a specific revision without making a commit on it.

`blob`::
	Convert raw file data into a blob, for future use in a
	`commit` command.  This command is optional and is not
	needed to perform an import.

`alias`::
	Record that a mark refers to a given object without first
	creating any new object.  Using --import-marks and referring
	to missing marks will cause fast-import to fail, so aliases
	can provide a way to set otherwise pruned commits to a valid
	value (e.g. the nearest non-pruned ancestor).

`checkpoint`::
	Forces fast-import to close the current packfile, generate its
	unique SHA-1 checksum and index, and start a new packfile.
	This command is optional