Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
This repository was archived by the owner on Nov 1, 2017. It is now read-only.

Fix typos#1075

Merged
tarebyte merged 1 commit intogithub:masterfromjwilk:spelling
Jun 9, 2016
Merged
Show file tree
Hide file tree
Changes fromall commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletioncontent/changes/2012-11-29-gitignore-templates.html
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 thethepublic [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:

Expand Down
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 toannouce 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 toannounce 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].

Expand Down
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 acompatability 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 acompatibility 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.

Expand Down
2 changes: 1 addition & 1 deletioncontent/changes/2014-10-24-status-api-limits.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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'thesistate to [contact] us.
If you have any feedback or questions, please don'thesitate to [contact] us.

[statuses]: /v3/repos/statuses/
[validation error]: https://developer.github.com/v3/#client-errors
Expand Down
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 useuseof 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
Expand DownExpand Up@@ -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 isanalagous to the
is a new API that isanalogous 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.

Expand Down
2 changes: 1 addition & 1 deletioncontent/changes/2015-06-24-licenses-api-update.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 inreponses from endpoints that list multiple repositories, such as [List organization repositories](/v3/repos/#list-organization-repositories):
Now, license information will also be included inresponses from endpoints that list multiple repositories, such as [List organization repositories](/v3/repos/#list-organization-repositories):

GET /orgs/github/repos

Expand Down
2 changes: 1 addition & 1 deletioncontent/guides/delivering-deployments.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 istrigged. That's
When a new deployment is created, a completely separate event istriggered. 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.

Expand Down
2 changes: 1 addition & 1 deletioncontent/guides/traversing-with-pagination.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 (`<<`) andfoward (`>>`) elements:
order to generate links for back (`<<`) andforward (`>>`) elements:

``` ruby
prev_page_href = client.last_response.rels[:prev] ? client.last_response.rels[:prev].href : "(none)"
Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/gists.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 betrucated 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 betruncated 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

Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/git/commits.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 tablebellow.
`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebelow.
`signature`|`string` | The signature that was extracted from the commit.
`payload`|`string` | The value that was signed.

Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/git/tags.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 tablebellow.
`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the tablebelow.
`signature`|`string` | The signature that was extracted from the tag.
`payload`|`string` | The value that was signed.

Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/migration/source_imports.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 ofoffiles 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

Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/repos/commits.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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 tablebellow.
`reason`|`string` | The reason for `verified` value. Possible values and their meanings are enumerated in the tablebelow.
`signature`|`string` | The signature that was extracted from the commit.
`payload`|`string` | The value that was signed.

Expand Down
2 changes: 1 addition & 1 deletioncontent/v3/repos/hooks.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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'srespositories, 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'srepositories, check out our [API documentation for Organization Webhooks][org-hooks].

## List hooks

Expand Down

[8]ページ先頭

©2009-2025 Movatter.jp