Support RFC 2822 date parsing in fast-import.
authorShawn O. Pearce <spearce@spearce.org>
Tue, 6 Feb 2007 19:58:30 +0000 (14:58 -0500)
committerShawn O. Pearce <spearce@spearce.org>
Tue, 6 Feb 2007 19:58:30 +0000 (14:58 -0500)
commit63e0c8b364e334fc7cc975edf1f16fb4c89594b3
tree85f4ed7849cf2799bb1dbcd0b696415f4b748d6a
parentef94edb53c9a5fd1e5fca9f548adc713d3d8ffe1
Support RFC 2822 date parsing in fast-import.

Since some frontends may be working with source material where
the dates are only readily available as RFC 2822 strings, it is
more friendly if fast-import exposes Git's parse_date() function
to handle the conversion.  This way the frontend doesn't need
to perform the parsing itself.

The new --date-format option to fast-import can be used by a
frontend to select which format it will supply date strings in.
The default is the standard `raw` Git format, which fast-import
has always supported.  Format rfc2822 can be used to activate the
parse_date() function instead.

Because fast-import could also be useful for creating new, current
commits, the format `now` is also supported to generate the current
system timestamp.  The implementation of `now` is a trivial call
to datestamp(), but is actually a whole whopping 3 lines so that
fast-import can verify the frontend really meant `now`.

As part of this change I have added validation of the `raw` date
format.  Prior to this change fast-import would accept anything
in a `committer` command, even if it was seriously malformed.
Now fast-import requires the '> ' near the end of the string and
verifies the timestamp is formatted properly.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Documentation/git-fast-import.txt
fast-import.c
t/t9300-fast-import.sh