Merge pull request #1075 from jwilk/spelling

Fix typos

content/changes/2012-11-29-gitignore-templates.html

@@ -6,7 +6,7 @@
 We recently [made it easy][init-post] to initialize a repository when you create
 it [via the API][repo-create]. One of the options you can pass when creating a
 repository is `gitignore_template`. This value is the name of one of the
-templates from the the public [GitHub .gitignore repository][templates-repo].
+templates from the public [GitHub .gitignore repository][templates-repo].
 
 The [Gitignore Templates API][new-api] makes it easy to list those templates:
 

content/changes/2014-04-22-deprecating-beta-media-type.md

@@ -5,7 +5,7 @@ author_name: jasonrudolph
 
 Now that the GitHub API is [serving the v3 media type by default][v3-default], we are deprecating the legacy [beta media type][beta].
 
-We will eventually remove support for the beta media type, but we have no official retirement date to annouce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in [just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.
+We will eventually remove support for the beta media type, but we have no official retirement date to announce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in [just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.
 
 As always, if you have any questions, please [get in touch][contact].
 

content/changes/2014-10-21-deployment-webhook-payload-changes.md

@@ -3,7 +3,7 @@ title: Deployment webhook payload changes
 author_name: atmos
 ---
 
-On November 4th, 2014, we will begin sending a new format for [deployment][1] and [deployment status][2] payloads for webhooks. In the meantime we'll be running in a compatability mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.
+On November 4th, 2014, we will begin sending a new format for [deployment][1] and [deployment status][2] payloads for webhooks. In the meantime we'll be running in a compatibility mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.
 
 This change brings the payloads for these events more inline with the responses you'd receive from the API. Instead of having deployment and deployment status attributes as top-level keys, we will now nest them under `deployment` and `deployment_status` keys. Since we're still in the [preview period][3] for the deployments API we felt it was best to correct this inconsistency now.
 

content/changes/2014-10-24-status-api-limits.md

@@ -9,7 +9,7 @@ to 1000 per commit SHA, repository, and context.
 Beginning Monday, November 3rd, we will trim existing data sets that exceed this limit, deleting the oldest
 records first.  Attempts to create statuses beyond that limit will result in a [validation error].
 
-If you have any feedback or questions, please don't hesistate to [contact] us.
+If you have any feedback or questions, please don't hesitate to [contact] us.
 
 [statuses]: /v3/repos/statuses/
 [validation error]: https://developer.github.com/v3/#client-errors

content/changes/2014-12-08-removing-authorizations-token.md

@@ -5,7 +5,7 @@ author_name: ptoomey3
 
 Since OAuth access tokens function like passwords, they should be treated with
 care. Today we are making it easier to more securely work with authorizations
-via the Authorizations API. We are deprecating the use use of the `token`
+via the Authorizations API. We are deprecating the use of the `token`
 attribute in the majority of the [Authorizations API](/v3/oauth_authorizations/)
 responses. For the [affected APIs][authorizations-token-deprecation-notice], the
 `token` attribute will soon return an empty string. To get ready for that
@@ -60,7 +60,7 @@ for the same client ID and user.
   [OAuth applications listing on GitHub][app-listing].
 
 * [Get-or-create an authorization for a specific app and fingerprint][get-or-create-for-app-fingerprint]
-is a new API that is analagous to the
+is a new API that is analogous to the
 [Get-or-create an authorization for a specific app][get-or-create-for-app]
 API, but adds support for the new `fingerprint` request parameter.
 

content/changes/2015-06-24-licenses-api-update.md

@@ -9,7 +9,7 @@ Before, license information was only returned for an individual repository:
 
     GET /repos/github/hubot
 
-Now, license information will also be included in reponses from endpoints that list multiple repositories, such as [List organization repositories](/v3/repos/#list-organization-repositories):
+Now, license information will also be included in responses from endpoints that list multiple repositories, such as [List organization repositories](/v3/repos/#list-organization-repositories):
 
     GET /orgs/github/repos
 

content/guides/delivering-deployments.md

@@ -125,7 +125,7 @@ Deployments can have some metadata attached to them, in the form of a `payload`
 and a `description`. Although these values are optional, it's helpful to use
 for logging and representing information.
 
-When a new deployment is created, a completely separate event is trigged. That's
+When a new deployment is created, a completely separate event is triggered. That's
 why we have a new `switch` case in the event handler for `deployment`. You can
 use this information to be notified when a deployment has been triggered.
 

content/guides/traversing-with-pagination.md

@@ -241,7 +241,7 @@ clicked_results = client.search_code('addClass user:mozilla', :page => random_pa
 ```
 
 If we wanted to get fancy, we could also grab the previous and next pages, in
-order to generate links for back (`<<`) and foward (`>>`) elements:
+order to generate links for back (`<<`) and forward (`>>`) elements:
 
 ``` ruby
 prev_page_href = client.last_response.rels[:prev] ? client.last_response.rels[:prev].href : "(none)"

content/v3/gists.md

@@ -20,7 +20,7 @@ The Gist API provides up to one megabyte of content for each file in the gist. E
 
 If you need the full contents of the file, you can make a `GET` request to the URL specified by `raw_url`. Be aware that for files larger than ten megabytes, you'll need to clone the gist via the URL provided by `git_pull_url`.
 
-In addition to a specific file's contents being truncated, the entire files list may be trucated if the total number exceeds 300 files. If the top level `truncated` key is `true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by `git_pull_url`.
+In addition to a specific file's contents being truncated, the entire files list may be truncated if the total number exceeds 300 files. If the top level `truncated` key is `true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by `git_pull_url`.
 
 ## List a user's gists
 

content/v3/git/commits.md

@@ -90,7 +90,7 @@ The response will include a `verification` field whose value is an object descri
 Name | Type | Description
 -----|------|--------------
 `verified`|`boolean` | Does GitHub consider the signature in this commit to be verified?
-`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table bellow.
+`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table below.
 `signature`|`string` | The signature that was extracted from the commit.
 `payload`|`string` | The value that was signed.
 

content/v3/git/tags.md

@@ -94,7 +94,7 @@ The response will include a `verification` field whose value is an object descri
 Name | Type | Description
 -----|------|--------------
 `verified`|`boolean` | Does GitHub consider the signature in this tag to be verified?
-`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table bellow.
+`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table below.
 `signature`|`string` | The signature that was extracted from the tag.
 `payload`|`string` | The value that was signed.
 

content/v3/migration/source_imports.md

@@ -175,7 +175,7 @@ This section includes details about Git LFS related fields that may be present i
 * `use_lfs` - describes whether the import has been opted in or out of using Git LFS. The value can be `opt_in`, `opt_out`, or `undecided` if no action has been taken.
 * `has_large_files` - the boolean value describing whether files larger than 100MB were found during the `importing` step.
 * `large_files_size` - the total size in gigabytes of files larger than 100MB found in the originating repository.
-* `large_files_count` - the total number of of files larger than 100MB found in the originating repository. To see a list of these files, make a "Get Large Files" request.
+* `large_files_count` - the total number of files larger than 100MB found in the originating repository. To see a list of these files, make a "Get Large Files" request.
 
 ## Update existing import
 

content/v3/repos/commits.md

@@ -116,7 +116,7 @@ The response will include a `verification` field whose value is an object descri
 Name | Type | Description
 -----|------|--------------
 `verified`|`boolean` | Does GitHub consider the signature in this commit to be verified?
-`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table bellow.
+`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the table below.
 `signature`|`string` | The signature that was extracted from the commit.
 `payload`|`string` | The value that was signed.
 

content/v3/repos/hooks.md

@@ -10,7 +10,7 @@ The Repository Webhooks API allows repository admins to manage the post-receive
 hooks for a repository.  Webhooks can be managed using the JSON HTTP API,
 or the [PubSubHubbub API](#pubsubhubbub).
 
-If you would like to set up a single webhook to receive events from all of your organization's respositories, check out our [API documentation for Organization Webhooks][org-hooks].
+If you would like to set up a single webhook to receive events from all of your organization's repositories, check out our [API documentation for Organization Webhooks][org-hooks].
 
 ## List hooks