Correct some language in fast-import documentation.
Minor documentation improvements, as suggested on the Git mailing list by Horst H. von Brand and Karl Hasselström. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit is contained in:
@ -181,7 +181,7 @@ If the local offset is not available in the source material, use
|
|||||||
``+0000'', or the most common local offset. For example many
|
``+0000'', or the most common local offset. For example many
|
||||||
organizations have a CVS repository which has only ever been accessed
|
organizations have a CVS repository which has only ever been accessed
|
||||||
by users who are located in the same location and timezone. In this
|
by users who are located in the same location and timezone. In this
|
||||||
case the offset from UTC can be easily assumed.
|
case a reasonable offset from UTC could be assumed.
|
||||||
+
|
+
|
||||||
Unlike the `rfc2822` format, this format is very strict. Any
|
Unlike the `rfc2822` format, this format is very strict. Any
|
||||||
variation in formatting will cause gfi to reject the value.
|
variation in formatting will cause gfi to reject the value.
|
||||||
@ -190,7 +190,7 @@ variation in formatting will cause gfi to reject the value.
|
|||||||
This is the standard email format as described by RFC 2822.
|
This is the standard email format as described by RFC 2822.
|
||||||
+
|
+
|
||||||
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
|
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
|
||||||
parser is accurate, but a little on the lenient side. Its the
|
parser is accurate, but a little on the lenient side. It is the
|
||||||
same parser used by gitlink:git-am[1] when applying patches
|
same parser used by gitlink:git-am[1] when applying patches
|
||||||
received from email.
|
received from email.
|
||||||
+
|
+
|
||||||
@ -205,14 +205,15 @@ contained in an RFC 2822 date string is used to adjust the date
|
|||||||
value to UTC prior to storage. Therefore it is important that
|
value to UTC prior to storage. Therefore it is important that
|
||||||
this information be as accurate as possible.
|
this information be as accurate as possible.
|
||||||
+
|
+
|
||||||
If the source material is formatted in RFC 2822 style dates,
|
If the source material uses RFC 2822 style dates,
|
||||||
the frontend should let gfi handle the parsing and conversion
|
the frontend should let gfi handle the parsing and conversion
|
||||||
(rather than attempting to do it itself) as the Git parser has
|
(rather than attempting to do it itself) as the Git parser has
|
||||||
been well tested in the wild.
|
been well tested in the wild.
|
||||||
+
|
+
|
||||||
Frontends should prefer the `raw` format if the source material
|
Frontends should prefer the `raw` format if the source material
|
||||||
is already in UNIX-epoch format, or is easily convertible to
|
already uses UNIX-epoch format, can be coaxed to give dates in that
|
||||||
that format, as there is no ambiguity in parsing.
|
format, or its format is easiliy convertible to it, as there is no
|
||||||
|
ambiguity in parsing.
|
||||||
|
|
||||||
`now`::
|
`now`::
|
||||||
Always use the current time and timezone. The literal
|
Always use the current time and timezone. The literal
|
||||||
|
|||||||
Reference in New Issue
Block a user