From 6c4859d70308493281f0835343a9b755f19f706c Mon Sep 17 00:00:00 2001 From: Jakub Wilk Date: Thu, 9 Jun 2016 23:10:34 +0200 Subject: [PATCH] Fix typos --- content/changes/2012-11-29-gitignore-templates.html | 2 +- content/changes/2014-04-22-deprecating-beta-media-type.md | 2 +- .../changes/2014-10-21-deployment-webhook-payload-changes.md | 2 +- content/changes/2014-10-24-status-api-limits.md | 2 +- content/changes/2014-12-08-removing-authorizations-token.md | 4 ++-- content/changes/2015-06-24-licenses-api-update.md | 2 +- content/guides/delivering-deployments.md | 2 +- content/guides/traversing-with-pagination.md | 2 +- content/v3/gists.md | 2 +- content/v3/git/commits.md | 2 +- content/v3/git/tags.md | 2 +- content/v3/migration/source_imports.md | 2 +- content/v3/repos/commits.md | 2 +- content/v3/repos/hooks.md | 2 +- 14 files changed, 15 insertions(+), 15 deletions(-) diff --git a/content/changes/2012-11-29-gitignore-templates.html b/content/changes/2012-11-29-gitignore-templates.html index 46cb7574aa..d88d39b88f 100644 --- a/content/changes/2012-11-29-gitignore-templates.html +++ b/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: diff --git a/content/changes/2014-04-22-deprecating-beta-media-type.md b/content/changes/2014-04-22-deprecating-beta-media-type.md index 94137ccf9c..e212e5ae0e 100644 --- a/content/changes/2014-04-22-deprecating-beta-media-type.md +++ b/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]. diff --git a/content/changes/2014-10-21-deployment-webhook-payload-changes.md b/content/changes/2014-10-21-deployment-webhook-payload-changes.md index b982566a20..e74d85137c 100644 --- a/content/changes/2014-10-21-deployment-webhook-payload-changes.md +++ b/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. diff --git a/content/changes/2014-10-24-status-api-limits.md b/content/changes/2014-10-24-status-api-limits.md index d748a17565..c58ae0ebe4 100644 --- a/content/changes/2014-10-24-status-api-limits.md +++ b/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 diff --git a/content/changes/2014-12-08-removing-authorizations-token.md b/content/changes/2014-12-08-removing-authorizations-token.md index a5fb8002ac..994fe04884 100644 --- a/content/changes/2014-12-08-removing-authorizations-token.md +++ b/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. diff --git a/content/changes/2015-06-24-licenses-api-update.md b/content/changes/2015-06-24-licenses-api-update.md index 67c7ffaded..26f5b340d3 100644 --- a/content/changes/2015-06-24-licenses-api-update.md +++ b/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 diff --git a/content/guides/delivering-deployments.md b/content/guides/delivering-deployments.md index 7ddb32df8a..218cadfd9b 100644 --- a/content/guides/delivering-deployments.md +++ b/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. diff --git a/content/guides/traversing-with-pagination.md b/content/guides/traversing-with-pagination.md index 498f9b2c82..ff4d11cf0b 100644 --- a/content/guides/traversing-with-pagination.md +++ b/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)" diff --git a/content/v3/gists.md b/content/v3/gists.md index 127940e465..1038a72acb 100644 --- a/content/v3/gists.md +++ b/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 diff --git a/content/v3/git/commits.md b/content/v3/git/commits.md index 8b6a43bcd0..e26e272085 100644 --- a/content/v3/git/commits.md +++ b/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. diff --git a/content/v3/git/tags.md b/content/v3/git/tags.md index 42ce97eca8..5b98a0dd3f 100644 --- a/content/v3/git/tags.md +++ b/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. diff --git a/content/v3/migration/source_imports.md b/content/v3/migration/source_imports.md index 48b778ea0c..044cc0079e 100644 --- a/content/v3/migration/source_imports.md +++ b/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 diff --git a/content/v3/repos/commits.md b/content/v3/repos/commits.md index 7c5020a242..7c7fe281ca 100644 --- a/content/v3/repos/commits.md +++ b/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. diff --git a/content/v3/repos/hooks.md b/content/v3/repos/hooks.md index 5df7278423..2208924598 100644 --- a/content/v3/repos/hooks.md +++ b/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