mirror of
https://github.com/git/git.git
synced 2024-11-18 02:53:55 +01:00
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:
parent
209f129857
commit
f842fdb01d
@ -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
|
||||
organizations have a CVS repository which has only ever been accessed
|
||||
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
|
||||
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.
|
||||
+
|
||||
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
|
||||
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
|
||||
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
|
||||
(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
|
||||
is already in UNIX-epoch format, or is easily convertible to
|
||||
that format, as there is no ambiguity in parsing.
|
||||
already uses UNIX-epoch format, can be coaxed to give dates in that
|
||||
format, or its format is easiliy convertible to it, as there is no
|
||||
ambiguity in parsing.
|
||||
|
||||
`now`::
|
||||
Always use the current time and timezone. The literal
|
||||
|
Loading…
Reference in New Issue
Block a user