stream.  This design allows a frontend
program to process an unlimited number of branches simultaneously,
generating commits in the order they are available from the source
data.  It also simplifies the frontend programs considerably.

fast-import does not use or alter the current working directory, or any
file within it.  (It does however update the current Git repository,
as referenced by `GIT_DIR`.)  Therefore an import frontend may use
the working directory for its own purposes, such as extracting file
revisions from the foreign source.  This ignorance of the working
directory also allows fast-import to run very quickly, as it does not
need to perform any costly file update operations when switching
between branches.

INPUT FORMAT
------------
With the exception of raw file data (which Git does not interpret)
the fast-import input format is text (ASCII) based.  This text based
format simplifies development and debugging of frontend programs,
especially when a higher level language such as Perl, Python or
Ruby is being used.

fast-import is very strict about its input.  Where we say SP below we mean
*exactly* one space.  Likewise LF means one (and only one) linefeed
and HT one (and only one) horizontal tab.
Supplying additional whitespace characters will cause unexpected
results, such as branch names or file names with leading or trailing
spaces in their name, or early termination of fast-import when it encounters
unexpected input.

Stream Comments
~~~~~~~~~~~~~~~
To aid in debugging frontends fast-import ignores any line that
begins with `#` (ASCII pound/hash) up to and including the line
ending `LF`.  A comment line may contain any sequence of bytes
that does not contain an LF and therefore may be used to include
any detailed debugging information that might be specific to the
frontend and useful when inspecting a fast-import data stream.

Date Formats
~~~~~~~~~~~~
The following date formats are supported.  A frontend should select
the format it will use for this import by passing the format name
in the --date-format=<fmt> command-line option.

`raw`::
	This is the Git native format and is `<time> SP <offutc>`.
	It is also fast-import's default format, if --date-format was
	not specified.
+
The time of the event is specified by `<time>` as the number of
seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
written as an ASCII decimal integer.
+
The local offset is specified by `<offutc>` as a positive or negative
offset from UTC.  For example EST (which is 5 hours behind UTC)
would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
The local offset does not affect `<time>`; it is used only as an
advisement to help formatting routines display the timestamp.
+
If the local offset is not available in the source material, use
``+0000'', or the most common local offset.  For example many
organizations have a CVS repository which has only ever been accessed
by users who are located in the same location and time zone.  In this
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