Update draft release notes to 1.9

diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index bf1a02a80d5f4a61f5bbd0d826ae7df3bce58911..fd22a9a0c1312382a972a39e06063e7ff77b027d 100644 (file)
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -251,7 +251,7 @@ 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 timezone.  In this
+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
@@ -271,7 +271,7 @@ 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 timezone/UTC offset information
+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.
@@ -287,13 +287,13 @@ format, or its format is easily convertible to it, as there is no
 ambiguity in parsing.
 
 `now`::
-       Always use the current time and timezone.  The literal
+       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 timezone of this system
+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
-timezone.
+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
@@ -361,8 +361,8 @@ and control the current import process.  More detailed discussion
        `--cat-blob-fd` or `stdout` if unspecified.
 
 `feature`::
-       Require that fast-import supports the specified feature, or
-       abort if it does not.
+       Enable the specified feature. This requires that fast-import
+       supports the specified feature, and aborts if it does not.
 
 `option`::
        Specify any of the options listed under OPTIONS that do not
@@ -380,8 +380,8 @@ change to the project.
        ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
        'committer' (SP <name>)? SP LT <email> GT SP <when> LF
        data
-       ('from' SP <committish> LF)?
-       ('merge' SP <committish> LF)?
+       ('from' SP <commit-ish> LF)?
+       ('merge' SP <commit-ish> LF)?
        (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
        LF?
 ....
@@ -460,9 +460,9 @@ as the current commit on that branch is automatically assumed to
 be the first ancestor of the new commit.
 
 As `LF` is not valid in a Git refname or SHA-1 expression, no
-quoting or escaping syntax is supported within `<committish>`.
+quoting or escaping syntax is supported within `<commit-ish>`.
 
-Here `<committish>` is any of the following:
+Here `<commit-ish>` is any of the following:
 
 * The name of an existing branch already in fast-import's internal branch
   table.  If fast-import doesn't know the name, it's treated as a SHA-1
@@ -509,7 +509,7 @@ additional ancestors (forming a 16-way merge).  For this reason
 it is suggested that frontends do not use more than 15 `merge`
 commands per commit; 16, if starting a new, empty branch.
 
-Here `<committish>` is any of the commit specification expressions
+Here `<commit-ish>` is any of the commit specification expressions
 also accepted by `from` (see above).
 
 `filemodify`
@@ -677,8 +677,8 @@ paths for a commit are encouraged to do so.
 `notemodify`
 ^^^^^^^^^^^^
 Included in a `commit` `<notes_ref>` command to add a new note
-annotating a `<committish>` or change this annotation contents.
-Internally it is similar to filemodify 100644 on `<committish>`
+annotating a `<commit-ish>` or change this annotation contents.
+Internally it is similar to filemodify 100644 on `<commit-ish>`
 path (maybe split into subdirectories). It's not advised to
 use any other commands to write to the `<notes_ref>` tree except
 `filedeleteall` to delete all existing notes in this tree.
@@ -691,7 +691,7 @@ External data format::
        commit that is to be annotated.
 +
 ....
-       'N' SP <dataref> SP <committish> LF
+       'N' SP <dataref> SP <commit-ish> LF
 ....
 +
 Here `<dataref>` can be either a mark reference (`:<idnum>`)
@@ -704,13 +704,13 @@ Inline data format::
        command.
 +
 ....
-       'N' SP 'inline' SP <committish> LF
+       'N' SP 'inline' SP <commit-ish> LF
        data
 ....
 +
 See below for a detailed description of the `data` command.
 
-In both formats `<committish>` is any of the commit specification
+In both formats `<commit-ish>` is any of the commit specification
 expressions also accepted by `from` (see above).
 
 `mark`
@@ -741,7 +741,7 @@ lightweight (non-annotated) tags see the `reset` command below.
 
 ....
        'tag' SP <name> LF
-       'from' SP <committish> LF
+       'from' SP <commit-ish> LF
        'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
        data
 ....
@@ -786,11 +786,11 @@ branch from an existing commit without creating a new commit.
 
 ....
        'reset' SP <ref> LF
-       ('from' SP <committish> LF)?
+       ('from' SP <commit-ish> LF)?
        LF?
 ....
 
-For a detailed description of `<ref>` and `<committish>` see above
+For a detailed description of `<ref>` and `<commit-ish>` see above
 under `commit` and `from`.
 
 The `LF` after the command is optional (it used to be required).