Documentation: Various corrections

Correct typos, spelling mistakes, and grammatical errors.

Change-Id: I80ec66de7b2228f9ff45a2f06faf576707195758

Documentation/access-control.txt

@@ -23,7 +23,7 @@ This is the Gerrit "root" identity.
 
 Users in the 'Administrators' group can perform any action under
 the Admin menu, to any group or project, without further validation
-of any other access controls.  In most installations only those
+or any other access controls.  In most installations only those
 users who have direct filesystem and database access would be
 placed into this group.
 
@@ -459,7 +459,7 @@ Create reference
 The create reference category controls whether it is possible to
 create new references, branches or tags.  This implies that the
 reference must not already exist, it's not a destructive permission
-in that you can't overwrite or remove any previosuly existing
+in that you can't overwrite or remove any previously existing
 references (and also discard any commits in the process).
 
 It's probably most common to either permit the creation of a single
@@ -470,7 +470,7 @@ This permission is often given in conjunction with regular push
 branch permissions, allowing the holder of both to create new branches
 as well as bypass review for new commits on that branch.
 
-To push lightweight (non annotated) tags, grant
+To push lightweight (non-annotated) tags, grant
 `Create Reference` for reference name `refs/tags/*`, as lightweight
 tags are implemented just like branches in Git.
 
@@ -823,7 +823,7 @@ Examples of typical roles in a project
 
 Below follows a set of typical roles on a server and which access
 rights these roles typically should be granted. You may see them as
-general guide lines for a typical way to set up your project on a
+general guidelines for a typical way to set up your project on a
 brand new Gerrit instance.
 
 [[examples_contributor]]
@@ -906,8 +906,8 @@ submit of the change even if someone else sets `Verify` +1.  Depending on the
 project and how much the CI system can be trusted for accurate results, a
 blocking label might not be feasible.  A recommended alternative is to set the
 label `Code-review` to -1 instead, as it isn't a blocking label but still
-shows a red label in the Gerrit UI.  Optionally; to enable the possibility to
+shows a red label in the Gerrit UI.  Optionally, to enable the possibility to
-deliver different results (build error vs unstable for instance) it's also
+deliver different results (build error vs unstable for instance), it's also
 possible to set `Code-review` +1 as well.
 
 If pushing new changes is granted, it's possible to automate cherry-pick of

Documentation/cmd-hook-commit-msg.txt

@@ -54,7 +54,7 @@ change viewed on the web.
 OBTAINING
 ---------
 To obtain the 'commit-msg' script use scp, wget or curl to download it
-to your local system from your gerrit server.
+to your local system from your Gerrit server.
 
 You can use either of the below commands:
 

Documentation/config-contact.txt

@@ -48,7 +48,7 @@ person's name here, but instead some sort of organizational role.
 The actual values chosen don't matter later, and are only to help
 document the purpose of the key.
 
-Chose a fairly long expiration period, such as 20 years.  For most
+Choose a fairly long expiration period, such as 20 years.  For most
 Gerrit instances, contact data will be written once, and rarely,
 if ever, read back.
 

Documentation/config-gerrit.txt

@@ -107,7 +107,7 @@ member of available as groups in Gerrit.
 * `CLIENT_SSL_CERT_LDAP`
 +
 This authentication type is actually kind of SSO. Gerrit will configure
-Jetty's SSL channel to request client's SSL certificate. For this
+Jetty's SSL channel to request the client's SSL certificate. For this
 authentication to work a Gerrit administrator has to import the root
 certificate of the trust chain used to issue the client's certificate
 into the <review-site>/etc/keystore.
@@ -161,7 +161,7 @@ By default, OpenID.
 +
 List of permitted OpenID providers.  A user may only authenticate
 with an OpenID that matches this list.  Only used if `auth.type`
-was set to OpenID (the default).
+is set to OpenID (the default).
 +
 Patterns may be either a
 link:http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html[standard
@@ -173,7 +173,7 @@ allowing users to authenticate with any OpenID provider.
 
 [[auth.trustedOpenID]]auth.trustedOpenID::
 +
-List of trusted OpenID providers.  Only used if `auth.type` was
+List of trusted OpenID providers.  Only used if `auth.type` is
 set to OpenID (the default).
 +
 In order for a user to take advantage of permissions beyond those
@@ -232,7 +232,7 @@ Default is 12 hours.
 [[auth.httpHeader]]auth.httpHeader::
 +
 HTTP header to trust the username from, or unset to select HTTP basic
-or digest authentication.  Only used if `auth.type` was set to HTTP.
+or digest authentication.  Only used if `auth.type` is set to HTTP.
 
 [[auth.logoutUrl]]auth.logoutUrl::
 +
@@ -513,7 +513,7 @@ within Gerrit, so the cache expire time is largely irrelevant.
 
 cache `"permission_sort"`::
 +
-Caches the order access control sections must be applied to a
+Caches the order in which access control sections must be applied to a
 reference.  Sorting the sections can be expensive when regular
 expressions are used, so this cache remembers the ordering for
 each branch.
@@ -570,7 +570,7 @@ cache.diff_intraline.maxIdleWorkers::
 Number of idle worker threads to maintain for the intraline difference
 computations.  There is no upper bound on how many concurrent requests
 can occur at once, if additional threads are started to handle a peak
-load, only this many will remaining idle afterwards.
+load, only this many will remain idle afterwards.
 +
 Default is 1.5x number of available CPUs.
 
@@ -646,7 +646,7 @@ will match typical Gerrit Change-Id values and create a hyperlink
 to changes which reference it.  The second configuration 'bugzilla'
 will hyperlink terms such as 'bug 42' to an external bug tracker,
 supplying the argument record number '42' for display.  The third
-configuration 'tracker' uses raw HTML to more preciously control
+configuration 'tracker' uses raw HTML to more precisely control
 how the replacement is displayed to the user.
 
 ----
@@ -1318,7 +1318,7 @@ By default, `$site_path/etc/keystore`.
 [[httpd.sslKeyPassword]]httpd.sslKeyPassword::
 +
 Password used to decrypt the private portion of the sslKeyStore.
-Java key stores require a password, even if the administrator
+Java keystores require a password, even if the administrator
 doesn't want to enable one.
 +
 If set to the empty string the embedded server will prompt for the
@@ -1338,7 +1338,7 @@ and false if httpd.listenUrl uses proxy-http:// or proxy-https://.
 [[httpd.acceptorThreads]]httpd.acceptorThreads::
 +
 Number of worker threads dedicated to accepting new incoming TCP
-connections and allocate them connection-specific resources.
+connections and allocating them connection-specific resources.
 +
 By default, 2, which should be suitable for most high-traffic sites.
 
@@ -1366,7 +1366,7 @@ By default 50.
 
 [[httpd.maxWait]]httpd.maxWait::
 +
-Maximum amount of time a client will wait to for an available
+Maximum amount of time a client will wait for an available
 thread to handle a project clone, fetch or push request over the
 smart HTTP transport.
 +
@@ -1391,7 +1391,7 @@ By default, 5 minutes.
 [[ldap]]Section ldap
 ~~~~~~~~~~~~~~~~~~~~
 
-LDAP integration is only enabled if `auth.type` was set to
+LDAP integration is only enabled if `auth.type` is set to
 `HTTP_LDAP`, `LDAP` or `CLIENT_SSL_CERT_LDAP`.  See above for a
 detailed description of the auth.type settings and their
 implications.
@@ -1459,7 +1459,7 @@ By default, `ignore`.
 _(Optional)_ The read timeout for an LDAP operation. The value is
 in the usual time-unit format like "1 s", "100 ms", etc...
 A timeout can be used to avoid blocking all of the SSH command start
-threads in case when the LDAP server becomes slow.
+threads in case the LDAP server becomes slow.
 +
 By default there is no timeout and Gerrit will wait for the LDAP
 server to respond until the TCP connection times out.
@@ -1506,8 +1506,8 @@ contains the initial value for the user's full name field in Gerrit.
 Typically this is the `displayName` property in LDAP, but could
 also be `legalName` or `cn`.
 +
-Attribute values may be concatenated with literal strings, for
+Attribute values may be concatenated with literal strings.  For
-example to join given name and surname together use the pattern
+example to join given name and surname together, use the pattern
 `${givenName} ${SN}`.
 +
 If set, users will be unable to modify their full name field, as
@@ -1528,7 +1528,7 @@ of sAMAccountName followed by a constant domain name, use
 `${sAMAccountName.toLowerCase}@example.com`.
 +
 If set, the preferred email address will be prefilled from LDAP,
-but users may still be able to register additional email address,
+but users may still be able to register additional email addresses,
 and select a different preferred email address.
 +
 Default is `mail`.
@@ -1618,7 +1618,7 @@ can be achieved.
 +
 If set, it must be ensured that the local usernames for all existing
 accounts are converted to lower case, otherwise a user that has a
-local username that contains upper case characters cannot login
+local username that contains upper case characters will not be able to login
 anymore. The local usernames for the existing accounts can be
 converted to lower case by running the server program
 link:pgm-LocalUsernamesToLowerCase.html[LocalUsernamesToLowerCase].
@@ -1728,7 +1728,7 @@ If an object is larger than the given size the pack-parsing will abort
 and the push operation will fail. If set to zero then there is no
 limit.
 +
-Gerrit administrator can use this setting to prevent developers
+Gerrit administrators can use this setting to prevent developers
 from pushing objects which are too large to Gerrit.
 +
 Default is zero.
@@ -1995,7 +1995,7 @@ By default, true.
 +
 Number of threads to use when executing SSH command requests.
 If additional requests are received while all threads are busy they
-are queued and serviced in a first-come-first-serve order.
+are queued and serviced in a first-come-first-served order.
 +
 By default, 1.5x the number of CPUs available to the JVM.
 
@@ -2062,7 +2062,7 @@ By default, 2 minutes.
 +
 Maximum number of concurrent SSH sessions that a user account
 may open at one time.  This is the number of distinct SSH logins
-the each user may have active at one time, and is not related to
+that each user may have active at one time, and is not related to
 the number of commands a user may issue over a single connection.
 If set to 0, there is no limit.
 +
@@ -2210,7 +2210,7 @@ Java regular expression (java.util.regex)] used to match the
 external tracking id part of the footer line. The match can
 result in several entries in the DB.  If grouping is used in the
 regex the first group will be interpreted as the tracking id.
-Tracking ids > 20 char will be ignored.
+Tracking ids longer than 20 characters will be ignored.
 +
 The configuration file parser eats one level of backslashes, so the
 character class `\s` requires `\\s` in the configuration file.  The
@@ -2219,7 +2219,7 @@ expression containing # must be wrapped in double quotes.
 
 [[trackingid.name.system]]trackingid.<name>.system::
 +
-The name of the external tracking system(max 10 char).
+The name of the external tracking system (maximum 10 characters).
 It is possible to have several trackingid entries for the same
 tracking system.
 

Documentation/config-gitweb.txt

@@ -27,7 +27,7 @@ Linux distributions.
 Alternatively, if Gerrit is served behind reverse proxy, it can
 generate different URLs for gitweb's links (they need to be
 rewritten to `<gerrit>/gitweb?args` on the web server). This allows
-for serving gitweb under different URL than the Gerrit instance.
+for serving gitweb under a different URL than the Gerrit instance.
 To enable this feature, set both: `gitweb.cgi` and `gitweb.url`.
 
 ====

Documentation/config-headerfooter.txt

@@ -42,7 +42,7 @@ and may be referenced in `GerritSite{Header,Footer}.html`
 or `GerritSite.css` by the relative URL `static/$name`
 (e.g. `static/logo.png`).
 
-To simplify security management, only files are served from
+To simplify security management, files are only served from
 `'$site_path'/static`.  Subdirectories are explicitly forbidden from
 being served from this location by enforcing the rule that file names
 cannot contain `/` or `\`.  (Client requests for `static/foo/bar`

Documentation/config-hooks.txt

@@ -88,7 +88,7 @@ Called whenever a user signs a contributor license agreement
 Configuration Settings
 ----------------------
 
-It is possible to change where gerrit looks for hooks, and what
+It is possible to change where Gerrit looks for hooks, and what
 filenames it looks for by adding a [hooks] section to gerrit.config.
 
 Gerrit will use the value of hooks.path for the hooks directory, and

Documentation/config-mail.txt

@@ -20,7 +20,7 @@ and modifying it will allow an administrator to customize the template.
 Supported Mail Templates:
 -------------------------
 
-Each mail that Gerrit sends out is controlled by at least one template, these
+Each mail that Gerrit sends out is controlled by at least one template.  These
 are listed below.  Change emails are influenced by two additional templates,
 one to set the subject line, and one to set the footer which gets appended to
 all the change emails (see `ChangeSubject.vm` and `ChangeFooter.vm` below.)
@@ -36,7 +36,7 @@ ChangeFooter.vm
 ~~~~~~~~~~~~~~~
 
 The `ChangeFooter.vm` template will determine the contents of the footer
-text that will be appended to emails related to changes (all `ChangeEmails)`.
+text that will be appended to emails related to changes (all `ChangeEmail`s).
 
 ChangeSubject.vm
 ~~~~~~~~~~~~~~~~
@@ -49,6 +49,7 @@ Comment.vm
 
 The `Comment.vm` template will determine the contents of the email related to
 a user submitting comments on changes.  It is a `ChangeEmail`: see
+`ChangeSubject.vm` and `ChangeFooter.vm`.
 
 Merged.vm
 ~~~~~~~~~
@@ -62,6 +63,7 @@ MergeFail.vm
 
 The `MergeFail.vm` template will determine the contents of the email related
 to a failure upon attempting to merge a change to the head.  It is a
+`ChangeEmail`: see `ChangeSubject.vm` and `ChangeFooter.vm`.
 
 NewChange.vm
 ~~~~~~~~~~~~
@@ -107,7 +109,7 @@ be necessary for anything more than a minor formatting change.
 Warning
 ~~~~~~~
 
-Be aware that modifying templates can cause them to fail to parse and therefor
+Be aware that modifying templates can cause them to fail to parse and therefore
 not send out the actual email, or worse, calling methods on the available
 objects could have internal side effects which would adversely affect the
 health of your Gerrit server and/or data.
@@ -125,7 +127,7 @@ or the current child class inherited from it.
 
 $messageClass::
 +
-A String containing the messageClass
+A String containing the messageClass.
 
 $StringUtils::
 +
@@ -139,35 +141,35 @@ All change related emails have the following additional variables available to t
 
 $change::
 +
-A reference to the current `Change` object
+A reference to the current `Change` object.
 
 $changeId::
 +
-Id of the current change (a `Change.Key`)
+Id of the current change (a `Change.Key`).
 
 $coverLetter::
 +
-The text of the `ChangeMessage`
+The text of the `ChangeMessage`.
 
 $branch::
 +
-A reference to the branch of this change (a `Branch.NameKey`)
+A reference to the branch of this change (a `Branch.NameKey`).
 
 $fromName::
 +
-The name of the from user
+The name of the from user.
 
 $projectName::
 +
-The name of this change's project
+The name of this change's project.
 
 $patchSet::
 +
-A reference to the current `PatchSet`
+A reference to the current `PatchSet`.
 
 $patchSetInfo::
 +
-A reference to the current `PatchSetInfo`
+A reference to the current `PatchSetInfo`.
 
 
 See Also

Documentation/config-reverseproxy.txt

@@ -5,7 +5,7 @@ Description
 -----------
 
 Gerrit can be configured to run behind a third-party web server.
-This allows the other web server to bind to the privileged ports 80
+This allows the other web server to bind to the privileged port 80
 (or 443 for SSL), as well as offloads the SSL processing overhead
 from Java to optimized native C code.
 

Documentation/config-sso.txt

@@ -146,7 +146,7 @@ To enable this form of authentication:
 The auth.type must always be HTTP, indicating the user identity
 will be obtained from the HTTP authorization data.
 
-The auth.httpHeader indicates which HTTP header field the Siteminder
+The auth.httpHeader indicates in which HTTP header field the Siteminder
 product has stored the username.  Usually this is "SM_USER", but
 may differ in your environment.  Please refer to your organization's
 single sign-on or security group to ensure the setting is correct.

Documentation/dev-design.txt

@@ -37,7 +37,7 @@ does not enforce peer-review prior to submission.
 
 Git is a distributed version control system, wherein each repository
 is assumed to be owned/maintained by a single user.  There are no
-inherit security controls built into Git, so the ability to read
+inherent security controls built into Git, so the ability to read
 from or write to a repository is controlled entirely by the host's
 filesystem access controls.  When multiple maintainers collaborate
 on a single shared repository a high degree of trust is required,

Documentation/dev-release.txt

@@ -192,7 +192,7 @@ because Status=Submitted is considered a closed issue.
 Mailing List
 ~~~~~~~~~~~~
 
-* Send an email to the mailing list to annouce the release
+* Send an email to the mailing list to announce the release
 * Consider including some or all of the following in the email:
 ** A link to the release and the release notes (if a final release)
 ** A link to the docs

Documentation/error-branch-not-found.txt

@@ -7,8 +7,8 @@ review if the specified target branch does not exist.
 To push a change for code review the commit has to be pushed to the
 project's magical `refs/for/'branch'` ref (for details have a look at
 link:user-upload.html#push_create[Create Changes]).
-If you specify a non existing branch in the `refs/for/'branch'` ref
+If you specify a non-existing branch in the `refs/for/'branch'` ref
-the push is failing with the error message 'branch ... not found'.
+the push fails with the error message 'branch ... not found'.
 
 To fix this problem verify
 

Documentation/error-change-closed.txt

@@ -14,7 +14,7 @@ already submitted and merged you may want to push your commit as a
 new change. To do this you have to remove the Change-Id from the
 commit message as explained link:error-push-fails-due-to-commit-message.html[here] and ideally generate a new Change-Id
 using the link:cmd-hook-commit-msg.html[commit hook] or EGit. Before pushing again it is also
-recommendable to do a link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[git rebase] to base your commit on the submitted
+recommended to do a link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[git rebase] to base your commit on the submitted
 change. Pushing again should now create a new change in Gerrit.
 
 If the change for which you wanted to upload a new patch set was

Documentation/error-change-does-not-belong-to-project.txt

@@ -7,7 +7,7 @@ that belongs to another project.
 This error message means that the user explicitly pushed a commit to
 a change that belongs to another project by specifying it as target
 ref. This way of adding a new patch set to a change is deprecated as
-explained link:user-upload.html#manual_replacement_mapping[here]. It is recommended to only rely on Change-ID's for
+explained link:user-upload.html#manual_replacement_mapping[here]. It is recommended to only rely on Change-IDs for
 link:user-upload.html#push_replace[replacing changes].
 
 

Documentation/error-change-not-found.txt

@@ -7,7 +7,7 @@ that cannot be found.
 This error message means that the user explicitly pushed a commit to
 a non-existing change by specifying it as target ref. This way of
 adding a new patch set to a change is deprecated as explained link:user-upload.html#manual_replacement_mapping[here].
-It is recommended to only rely on Change-ID's for link:user-upload.html#push_replace[replacing changes].
+It is recommended to only rely on Change-IDs for link:user-upload.html#push_replace[replacing changes].
 
 
 GERRIT

Documentation/error-no-changes-made.txt

@@ -2,10 +2,10 @@ no changes made
 ===============
 
 With this error message Gerrit rejects to push a commit as a new
-patch set for a change, if the pushed commit is identical with the
+patch set for a change, if the pushed commit is identical to the
 current patch set of this change.
 
-A pushed commit is considered to be identical with the current patch
+A pushed commit is considered to be identical to the current patch
 set if
 
 - the files in the commit,

Documentation/error-no-new-changes.txt

@@ -3,7 +3,7 @@ no new changes
 
 With this error message Gerrit rejects to push a commit if the pushed
 commit was already successfully pushed to Gerrit. In this case there
-is no new change and consequently there is nothing to do for Gerrit.
+is no new change and consequently there is nothing for Gerrit to do.
 
 If your push is failing with this error message, you normally
 don't have to do anything since the commit was already successfully

Documentation/error-non-fast-forward.txt

@@ -1,15 +1,15 @@
 non-fast forward
 ================
 
-With this error message Git rejects a push if the remote branch can't
+With this error message Gerrit rejects a push if the remote branch can't
 be fast forwarded onto the pushed commit. This is the case if the
 pushed commit is not based on the current tip of the remote branch.
 
 If a non-fast forward update would be done, all commits from the
 remote branch that succeed the base commit of the pushed commit would
 be removed. This would be especially confusing for other users that
-have based their work on such a commit. Because of this Git is by
+have based their work on such a commit. Because of this Git by
-default not allowing non-fast forward updates.
+default does not allow non-fast forward updates.
 
 When working with Gerrit, this error can only occur if
 link:user-upload.html#bypass_review[code review is bypassed].
@@ -46,7 +46,7 @@ should check the push specification and verify that you are pushing
 the commit to the correct project.
 
 
-Although it is considered as bad practice, it is possible to allow
+Although it is considered bad practice, it is possible to allow
 non-fast forward updates with Git. For this the remote Git repository
 has to be configured to not deny non-fast forward updates (set the
 link:http://www.kernel.org/pub/software/scm/git/docs/git-config.html[Git configuration] parameter 'receive.denyNonFastForwards' to

Documentation/error-not-a-gerrit-administrator.txt

@@ -1,7 +1,7 @@
 Not a Gerrit administrator
 ==========================
 
-With this error message Gerrit rejects to execute a SSH command that
+With this error message Gerrit rejects to execute an SSH command that
 requires administrator privileges if the user is not a Gerrit
 administrator.
 

Documentation/error-not-a-gerrit-project.txt

@@ -18,7 +18,7 @@ If you are facing this problem, do the following:
   project is listed. If the project is not listed the project either
   does not exist or you don't have
   link:access-control.html#category_read['Read'] access for it. This
-  means if you certain that the project name is right you should
+  means if you are certain that the project name is right you should
   contact the Gerrit Administrator or project owner to request access
   to the project.
 

Documentation/error-not-allowed-to-upload-merges.txt

@@ -2,11 +2,11 @@ you are not allowed to upload merges
 ====================================
 
 With this error message Gerrit rejects to push a merge commit if the
-pushing user has no permissions to upload merge commits for the
+pushing user has no permission to upload merge commits for the
 project to which the push is done.
 
 If you need to upload merge commits, you can contact one of the
-project owners and request permissions to upload merge commits
+project owners and request permission to upload merge commits
 (access right link:access-control.html#category_push_merge['Push Merge Commit'])
 for this project.
 

Documentation/error-permission-denied.txt

@@ -1,7 +1,7 @@
 Permission denied (publickey)
 =============================
 
-With this error message a SSH command to Gerrit is rejected if the
+With this error message an SSH command to Gerrit is rejected if the
 SSH authentication is not successful.
 
 The link:http://en.wikipedia.org/wiki/Secure_Shell[SSH] protocol uses link:http://en.wikipedia.org/wiki/Public-key_cryptography[Public-key Cryptography] for authentication.

Documentation/error-prohibited-by-gerrit.txt

@@ -20,7 +20,7 @@ In particular this error occurs:
 4. if you push a lightweight tag without the access right link:access-control.html#category_create['Create
    Reference'] for the reference name 'refs/tags/*'
 
-For new users it happens often that they accidentally try to bypass
+For new users it often happens that they accidentally try to bypass
 code review. The push then fails with the error message 'prohibited
 by Gerrit' because the project didn't allow to bypass code review.
 Bypassing the code review is done by pushing directly to refs/heads/*

Documentation/error-push-fails-due-to-commit-message.txt

@@ -3,7 +3,7 @@ Push fails due to commit message
 
 If Gerrit rejects pushing a commit it is often the case that there is
 an issue with the commit message of the pushed commit. In this case
-often the problem can be resolved by fixing the commit message.
+the problem can often be resolved by fixing the commit message.
 
 If the commit message of the last commit needs to be fixed you can
 simply amend the last commit (please find a detailed description in

Documentation/error-squash-commits-first.txt

@@ -9,7 +9,7 @@ the corresponding change in Gerrit, a dependency upon itself. Gerrit
 prevents such dependencies between patch sets within the same change
 to keep the review process simple. Otherwise reviewers would not only
 have to review the latest patch set but also all the patch sets the
-latest one is depending on.
+latest one depends on.
 
 This error is quite common, it appears when a user tries to address
 review comments and creates a new commit instead of amending the
@@ -93,8 +93,8 @@ the link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git doc
 ----
 
 If it was the intention to create a patch series with multiple
-changes to be reviewed each commit message should contain the
+changes to be reviewed, each commit message should contain the
-Change-ID of the corresponding change in Gerrit, if a change in
+Change-ID of the corresponding change in Gerrit.  If a change in
 Gerrit does not exist yet, the Change-ID should be generated (either
 by using a link:cmd-hook-commit-msg.html[commit hook] or by using EGit) or the Change-ID could be
 removed (not recommended since then amending this commit to create

Documentation/error-you-are-not-author.txt

@@ -1,7 +1,7 @@
 you are not author ...
 ======================
 
-Gerrit verifies for every pushed commit that the e-mail address of
+For every pushed commit Gerrit verifies that the e-mail address of
 the author matches one of the registered e-mail addresses of the
 pushing user. If this is not the case pushing the commit fails with
 the error message "you are not author ...". This policy can be
@@ -27,7 +27,7 @@ Configuration of e-mail address in Gerrit
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Check in Gerrit under 'Settings -> Identities' which e-mail addresses
-you've configured for your Gerrit account, if no e-mail address is
+you've configured for your Gerrit account.  If no e-mail address is
 registered go to 'Settings -> Contact Information' and register a new
 e-mail address there. Make sure you confirm your e-mail address by
 clicking on the link in the e-mail verification mail sent by Gerrit.
@@ -92,7 +92,7 @@ gets more complicated. In this case you have to do an interactive
 git rebase for the affected commits. While doing the interactive
 rebase you have to choose 'edit' for those commits for which the
 author should be rewritten. When the rebase stops at such a commit
-you have to amend the commit with explicitly setting the author
+you have to amend the commit, explicitly setting the author
 before continuing the rebase.
 
 Here is an example that shows how the interactive rebase is used to

Documentation/error-you-are-not-committer.txt

@@ -1,7 +1,7 @@
 you are not committer ...
 =========================
 
-Gerrit verifies for every pushed commit that the e-mail address of
+For every pushed commit Gerrit verifies that the e-mail address of
 the committer matches one of the registered e-mail addresses of the
 pushing user. If this is not the case pushing the commit fails with
 the error message "you are not committer ...". This policy can be
@@ -29,7 +29,7 @@ Configuration of e-mail address in Gerrit
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Check in Gerrit under 'Settings -> Identities' which e-mail addresses
-you've configured for your Gerrit account, if no e-mail address is
+you've configured for your Gerrit account.  If no e-mail address is
 registered go to 'Settings -> Contact Information' and register a new
 e-mail address there. Make sure you confirm your e-mail address by
 clicking on the link in the e-mail verification mail sent by Gerrit.

Documentation/i18n-readme.txt

@@ -1,7 +1,7 @@
 Gerrit Code Review - i18n
 =========================
 
-Aside from actually writing translations, there's some issues with
+Aside from actually writing translations, there are some issues with
 the way the code produces output.  Most of the UI should support
 right-to-left (RTL) languages.
 

Documentation/install-j2ee.txt

@@ -44,7 +44,7 @@ is configured and enabled within the DataSource.
 +
 If you enabled Bouncy Castle Crypto during 'init', copy the JAR
 from `'$site_path'/lib` into your servlet container's extensions
-directory so its available to Gerrit Code Review.
+directory so it's available to Gerrit Code Review.
 
 
 Jetty 7.x

Documentation/install-quick.txt

@@ -12,7 +12,7 @@ It is presumed you install it on a Unix based server such as any of the Linux
 flavors or BSD.
 
 It's also presumed that you have access to an OpenID enabled email address.
-Examples of OpenID enable email providers are gmail, yahoo and hotmail.
+Examples of OpenID enable email providers are Gmail, Yahoo! Mail and Hotmail.
 It's also possible to register a custom email address with OpenID, but that is
 outside the scope of this quick installation guide. For testing purposes one of
 the above providers should be fine. Please note that network access to the
@@ -42,7 +42,7 @@ If Java isn't installed, get it:
 Create a user to host the Gerrit service
 ----------------------------------------
 
-We will run the service as a non privileged user on your system.
+We will run the service as a non-privileged user on your system.
 First create the user and then become the user:
 
 ----
@@ -50,7 +50,7 @@ First create the user and then become the user:
   $ sudo su gerrit2
 ----
 
-If you don't have root privileges you could skip this step and run gerrit
+If you don't have root privileges you could skip this step and run Gerrit
 as your own user as well.
 
 
@@ -58,7 +58,7 @@ as your own user as well.
 Download Gerrit
 ---------------
 
-It's time to download the archive that contains the gerrit web and ssh service.
+It's time to download the archive that contains the Gerrit web and ssh service.
 
 You can choose from different versions to download from here:
 
@@ -87,8 +87,8 @@ It's time to run the initialization, and with the batch switch enabled, we don't
 When the init is complete, you can review your settings in the
 file `'$site_path/etc/gerrit.config'`.
 
-An important setting will be the canonicalWebUrl which will
+An important setting is the canonicalWebUrl which will
-be needed later to access gerrit's web interface.
+be needed later to access Gerrit's web interface.
 
 ----
   gerrit2@host:~$ cat ~/gerrit_testsite/etc/gerrit.config | grep canonical
@@ -216,7 +216,7 @@ Project creation
 Your base Gerrit server is now running and you have a user that's ready
 to interact with it.  You now have two options, either you create a new
 test project to work with or you already have a git with history that
-you would like to import into gerrit and try out code review on.
+you would like to import into Gerrit and try out code review on.
 
 New project from scratch
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -231,14 +231,14 @@ This is done via the SSH port:
   user@host:~$
 ----
 
-This will create a repository that you could clone to work with.
+This will create a repository that you can clone to work with.
 
 Already existing project
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 The other alternative is if you already have a git project that you
 want to try out Gerrit on.
-First you have to create the project, this is done via the SSH port:
+First you have to create the project.  This is done via the SSH port:
 
 ----
   user@host:~$ ssh -p 29418 user@localhost gerrit create-project --name demo-project
@@ -262,7 +262,7 @@ After that it's time to upload the previous history to the server:
   user@host:~/my-project$
 ----
 
-This will create a repository that you could clone to work with.
+This will create a repository that you can clone to work with.
 
 
 My first change
@@ -294,7 +294,7 @@ Then make a change to it and upload it as a reviewable change in Gerrit.
 
 Usually when you push to a remote git, you push to the reference
 `'/refs/heads/branch'`, but when working with Gerrit you have to push to a
-virtual branch representing "code review before submittal to branch".
+virtual branch representing "code review before submission to branch".
 This virtual name space is known as /refs/for/<branch>
 
 ----
@@ -319,11 +319,11 @@ Quick Installation Complete
 ---------------------------
 
 This covers the scope of getting Gerrit started and your first change uploaded.
-It doesn't give any clue as to how the review workflow works, please find
+It doesn't give any clue as to how the review workflow works, please read
 link:http://source.android.com/submit-patches/workflow[Default Workflow] to
 learn more about the workflow of Gerrit.
 
-To read more on the installation of Gerrit please read link:install.html[the detailed
+To read more on the installation of Gerrit please see link:install.html[the detailed
 installation page].
 
 

Documentation/install.txt

@@ -199,7 +199,7 @@ Site Customization
 ------------------
 
 Gerrit Code Review supports some site-specific customization options.
-For more information, see the related topic in this manual:
+For more information, see the related topics in this manual:
 
 * link:config-reverseproxy.html[Reverse Proxy]
 * link:config-sso.html[Single Sign-On Systems]

Documentation/intro-quick.txt

@@ -27,7 +27,7 @@ applied to the code base. However Gerrit goes a step further making it
 simple for all committers on a project to ensure that changes are
 checked over before they're actually applied. Because of this Gerrit
 is equally useful where all users are trusted committers such as may
-the case with closed-source commercial development. Either way it's
+be the case with closed-source commercial development. Either way it's
 still desirable to have code reviewed to improve the quality and
 maintainability of the code. After all, if only one person has seen
 the code it may be a little difficult to maintain when that person
@@ -337,7 +337,7 @@ HEAD is now at d5dacdb... Change to a proper, yeast based pizza dough.
 Easy as that, we now have the change in our working copy to play with.
 You might be interested in what the numbers of the refspec mean.
 
-* The first *68* is the id if the change +mod 100+.  The only reason
+* The first *68* is the id of the change +mod 100+.  The only reason
 for this initial number is to reduce the number of files in any given
 directory within the git repository.
 * The second *68* is the full id of the change. You'll notice this in
@@ -379,7 +379,7 @@ main screen. Just as Code Review and Verify are different operations
 that can be done by different users, Submission is a third operation
 that can be limited down to another group of users.
 
-Activating the _Publish and Submit_ or _Submit Patch Set X_ button
+Clicking the _Publish and Submit_ or _Submit Patch Set X_ button
 will merge the change into the main part of the repository so that it
 becomes an accepted part of the project. After this anyone fetching
 the git repository will receive this change as a part of the master

Documentation/json.txt

@@ -11,22 +11,22 @@ change
 ------
 The Gerrit change being reviewed, or that was already reviewed.
 
-project:: Project path in Gerrit
+project:: Project path in Gerrit.
 
-branch:: Branch name within project
+branch:: Branch name within project.
 
-topic:: Topic name specified by the uploader for this change series
+topic:: Topic name specified by the uploader for this change series.
 
 id:: Change identifier, as scraped out of the Change-Id field in
 the commit message, or as assigned by the server if it was missing.
 
-number:: Change number (deprecated)
+number:: Change number (deprecated).
 
-subject:: Description of change
+subject:: Description of change.
 
-owner:: Owner in <<account,account attribute>>
+owner:: Owner in <<account,account attribute>>.
 
-url:: Canonical URL to reach this change
+url:: Canonical URL to reach this change.
 
 commitMessage:: The full commit message for the change.
 
@@ -118,7 +118,7 @@ oldRev:: The old value of the ref, prior to the update.
 
 newRev:: The new value the ref was updated to.
 
-project:: Project path in Gerrit
+project:: Project path in Gerrit.
 
 refName:: Ref name within project.
 

Documentation/pgm-ExportReviewNotes.txt

@@ -14,7 +14,7 @@ DESCRIPTION
 -----------
 Scans every submitted change and creates an initial notes
 branch detailing the previous submission information for
-each merged changed.
+each merged change.
 
 This task can take quite some time, but can run in the background
 concurrently to the server if the database is MySQL or PostgreSQL.

Documentation/pgm-init.txt

@@ -19,7 +19,7 @@ Creates a new Gerrit server installation, interactively prompting
 for some basic setup prior to writing default configuration files
 into a newly created `$site_path`.
 
-If run an an existing `$site_path`, init will upgrade some resources
+If run in an existing `$site_path`, init will upgrade some resources
 as necessary.
 
 OPTIONS

Documentation/rest-api.txt

@@ -32,7 +32,7 @@ by setting the `Accept` HTTP request header to include
 ----
 
 JSON responses are encoded using UTF-8 and use content type
-`application/json`. The JSON response body starts with magic prefix
+`application/json`. The JSON response body starts with a magic prefix
 line that must be stripped before feeding the rest of the response
 body to a JSON parser:
 

Documentation/user-changeid.txt

@@ -4,7 +4,7 @@ Gerrit Code Review - Change-Ids
 Description
 -----------
 
-Gerrit Code Review sometimes relies upon Change-Id lines in the
+Gerrit Code Review sometimes relies upon a Change-Id line at the
 bottom of a commit message to uniquely identify a change across all
 drafts of it.  By including a unique Change-Id in the commit message,
 Gerrit can automatically associate a new version of a change back
@@ -37,7 +37,7 @@ is the unique identity assigned to this change.  It does not match
 the commit name, `29a6...`, as the change may have been amended or
 rebased to address reviewer comments since its initial inception.
 
-To avoid confusion with commit names, Change-Ids typically are with
+To avoid confusion with commit names, Change-Ids are typically prefixed with
 an uppercase `I`.
 
 Creation
@@ -125,7 +125,7 @@ When faced with multiple lines, try to preserve a line which was
 already uploaded to Gerrit Code Review, and thus has a corresponding
 change that reviewers have already examined and left comments on.
 If you aren't sure which lines Gerrit knows about, try copying and
-pasting the lines into the search box in the top-right.
+pasting the lines into the search box at the top-right of the web interface.
 
 If Gerrit already knows about more than one Change-Id, pick one
 to keep in the squashed commit message, and manually abandon the

Documentation/user-search.txt

@@ -149,7 +149,7 @@ library] is used for evaluation of such patterns.
 [[tr,bug]]
 tr:'ID', bug:'ID'::
 +
-Search for changes whose commit message contains 'ID' and matched
+Search for changes whose commit message contains 'ID' and matches
 one or more of the
 link:config-gerrit.html#trackingid[trackingid sections]
 in the server's configuration file.  This is typically used to
@@ -166,7 +166,7 @@ of the argument.
 [[message]]
 message:'MESSAGE'::
 +
-Changes that matches 'MESSAGE' arbitrary string in body commit messages.
+Changes that match 'MESSAGE' arbitrary string in the commit message body.
 
 [[file]]
 file:^'REGEX'::
@@ -229,7 +229,7 @@ Same as `reviewer:self`.
 
 is:open::
 +
-True if the change is other open or submitted, merge pending.
+True if the change is either open or submitted, merge pending.
 
 is:draft::
 +
@@ -246,7 +246,7 @@ Same as <<status,status:'STATE'>>.
 [[status]]
 status:open::
 +
-True if the change state is other 'review in progress' or 'submitted,
+True if the change state is either 'review in progress' or 'submitted,
 merge pending'.
 
 status:reviewed::
@@ -268,7 +268,7 @@ Change has been merged into the branch.
 
 status:abandoned::
 +
-Change has been abandoned by the change owner, or administrator.
+Change has been abandoned by the change owner, or an administrator.
 
 
 Boolean Operators
@@ -304,7 +304,7 @@ that are returned, as more changes are considered.
 [[labels]]
 Labels
 ------
-Label operators can be used to match approval score given during
+Label operators can be used to match approval scores given during
 a code review.  The specific set of supported labels depends on
 the server configuration, however `CodeReview` and `Verified`
 are the default labels provided out of the box.
@@ -323,7 +323,7 @@ A label name is any of the following:
   of change list pages.  Example: `label:R` or `label:V`.
 
 A label name must be followed by a score, or an operator and a score.
-The easiest way to explain these are by example.
+The easiest way to explain this is by example.
 
 `label:CodeReview=2`::
 `label:CodeReview=+2`::
@@ -400,7 +400,7 @@ The special case `watchedby:self` applies to the caller.
 
 draftby:'USER'::
 +
-Matches changes that 'USER' has left unpublished drafts on.
+Matches changes that 'USER' has left unpublished draft comments on.
 Since the drafts are unpublished, it is not possible to see the
 draft text, or even how many drafts there are. The special case
 of `draftby:self` will find changes where the caller has created

Documentation/user-submodules.txt

@@ -18,7 +18,7 @@ to identify if it registers git submodules (if the commit registers
 any gitlinks and .gitmodules file with required info) and if so,
 a new submodule subscription is registered.
 
-When a new commit of a registered submodule is merged, gerrit
+When a new commit of a registered submodule is merged, Gerrit
 automatically updates the subscribers to the submodule with a new
 commit having the updated gitlinks.
 
@@ -31,7 +31,7 @@ is to provide a brief overview, further details can be found
 in the official git submodule command documentation.
 
 Imagine a repository called 'super' and another one called 'a'.
-Also consider 'a' available in a running gerrit instance on "server".
+Also consider 'a' available in a running Gerrit instance on "server".
 With this feature, one could attach 'a' inside of 'super' repository
 at path 'a' by executing the following command when being inside
 'super':
@@ -86,12 +86,12 @@ has the same name as the destination branch of the commit having
 gitlinks/.gitmodules file.
 
 The branch field of a submodule section is a custom git submodule
-feature for gerrit use. One should always be sure to fill it in
+feature for Gerrit use. One should always be sure to fill it in
 editing .gitmodules file after adding submodules to a super project,
-if it is the intention to make use of the gerrit feature introduced here.
+if it is the intention to make use of the Gerrit feature introduced here.
 
 Any git submodules which are added and not have the branch field
-available in the .gitmodules file will not be subscribed by gerrit
+available in the .gitmodules file will not be subscribed by Gerrit
 to automatically update the superproject.
 
 Detecting and Subscribing Submodules
@@ -114,7 +114,7 @@ is updated.
 
 Imagine a superproject called 'super' having a branch called 'dev'
 having subscribed to a submodule 'a' on a branch 'dev-of-a'. When a commit
-is merged in branch 'dev-of-a' of 'a' project, gerrit automatically
+is merged in branch 'dev-of-a' of 'a' project, Gerrit automatically
 creates a new commit on branch 'dev' of 'super' updating the gitlink
 to point to the just merged commit.
 
@@ -123,11 +123,11 @@ Canonical Web Url
 
 Gerrit will automatically update only the superprojects that added
 the submodules of urls of the running server (the one described in
-the canonical web url value in gerrit configuration file).
+the canonical web url value in Gerrit configuration file).
 
 The Gerrit instance administrator group should always certify to
 provide the canonical web url value in its configuration file. Users
-should certify to use the url value of the running gerrit instance to
+should certify to use the url value of the running Gerrit instance to
 add/subscribe submodules.
 
 Removing Subscriptions

Documentation/user-upload.txt

@@ -46,7 +46,7 @@ and paste it into Gerrit's web interface:
 
 [TIP]
 Users who frequently upload changes will also want to consider
-starting a `ssh-agent`, and adding their private key to the list
+starting an `ssh-agent`, and adding their private key to the list
 managed by the agent, to reduce the frequency of entering the
 key's passphrase.  Consult `man ssh-agent`, or your SSH client's
 documentation, for more details on configuration of the agent
@@ -57,7 +57,7 @@ Testing Connections
 ~~~~~~~~~~~~~~~~~~~
 
 To verify your SSH key is working correctly, try using an SSH client
-to connect to Gerrit's SSHD port.  By default Gerrit is running on
+to connect to Gerrit's SSHD port.  By default Gerrit runs on
 port 29418, using the same hostname as the web server:
 
 ====
@@ -104,7 +104,7 @@ git push
 Create Changes
 ~~~~~~~~~~~~~~
 
-To create new changes for review, simply push into the project's
+To create new changes for review, simply push to the project's
 magical `refs/for/'branch'` ref using any Git client tool:
 
 ====