CARVIEW |
Select Language
HTTP/2 302
server: nginx
date: Mon, 25 Aug 2025 01:04:02 GMT
content-type: text/plain; charset=utf-8
content-length: 0
x-archive-redirect-reason: found capture at 20130729012304
location: https://web.archive.org/web/20130729012304/https://developer.github.com/changes.atom
server-timing: captures_list;dur=0.600381, exclusion.robots;dur=0.019604, exclusion.robots.policy;dur=0.009127, esindex;dur=0.014545, cdx.remote;dur=9.269698, LoadShardBlock;dur=378.739422, PetaboxLoader3.datanode;dur=65.504963, PetaboxLoader3.resolve;dur=131.065916
x-app-server: wwwb-app223
x-ts: 302
x-tr: 418
server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0
set-cookie: wb-p-SERVER=wwwb-app223; path=/
x-location: All
x-rl: 0
x-na: 0
x-page-cache: MISS
server-timing: MISS
x-nid: DigitalOcean
referrer-policy: no-referrer-when-downgrade
permissions-policy: interest-cohort=()
HTTP/2 200
server: nginx
date: Mon, 25 Aug 2025 01:04:02 GMT
content-type: application/atom+xml
content-length: 56799
x-archive-orig-server: GitHub.com
x-archive-orig-last-modified: Tue, 23 Jul 2013 13:29:22 GMT
x-archive-orig-expires: Thu, 25 Jul 2013 22:46:41 GMT
x-archive-orig-cache-control: max-age=600
x-archive-orig-content-length: 56799
x-archive-orig-accept-ranges: bytes
x-archive-orig-date: Mon, 29 Jul 2013 01:23:03 GMT
x-archive-orig-via: 1.1 varnish
x-archive-orig-age: 269183
x-archive-orig-connection: close
x-archive-orig-x-served-by: cache-v42-ASH
x-archive-orig-x-cache: HIT
x-archive-orig-x-cache-hits: 1
x-archive-orig-x-timer: S1375060983.872571945,VS0,VE0
x-archive-orig-vary: Accept-Encoding
cache-control: max-age=1800
x-archive-guessed-content-type: text/xml
x-archive-guessed-charset: utf-8
memento-datetime: Mon, 29 Jul 2013 01:23:04 GMT
link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate", ; rel="first memento"; datetime="Fri, 07 Sep 2012 19:08:40 GMT", ; rel="prev memento"; datetime="Thu, 13 Jun 2013 17:53:31 GMT", ; rel="memento"; datetime="Mon, 29 Jul 2013 01:23:04 GMT", ; rel="next memento"; datetime="Thu, 01 Aug 2013 18:39:28 GMT", ; rel="last memento"; datetime="Sat, 26 Jul 2025 13:16:31 GMT"
content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org
x-archive-src: alexa20130729-59/51_35_20130729011638_crawl101.arc.gz
server-timing: captures_list;dur=1.046969, exclusion.robots;dur=0.019867, exclusion.robots.policy;dur=0.007721, esindex;dur=0.013752, cdx.remote;dur=6.001193, LoadShardBlock;dur=192.872312, PetaboxLoader3.datanode;dur=165.882442, PetaboxLoader3.resolve;dur=378.963593, load_resource;dur=430.632992
x-app-server: wwwb-app223
x-ts: 200
x-tr: 673
server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0
x-location: All
x-rl: 0
x-na: 0
x-page-cache: MISS
server-timing: MISS
x-nid: DigitalOcean
referrer-policy: no-referrer-when-downgrade
permissions-policy: interest-cohort=()
accept-ranges: bytes
https://developer.github.com/
GitHub API Changes
2013-07-19T05:00:00Z
technoweenie
https://github.com/technoweenie
tag:developer.github.com,2013-07-19:/changes/2013-07-19-preview-the-new-search-api/
Preview the New Search API
2013-07-19T05:00:00Z
2013-07-19T05:00:00Z
jasonrudolph
https://github.com/technoweenie
<p>Today we’re excited to announce a <a href="/v3/search/">brand new Search API</a>. Whether you’re
searching for <a href="/v3/search/#search-code">code</a>, <a href="/v3/search/#search-repositories">repositories</a>,
<a href="/v3/search/#search-issues">issues</a>, or <a href="/v3/search/#search-users">users</a>, all the query abilities of
github.com are now available via the API as well.</p>
<p>Maybe you want to find <a href="/v3/search/#repository-search-example">popular Tetris implementations written in Assembly</a>.
We’ve got you covered.
Or perhaps you’re looking for <a href="/v3/search/#code-search-example">new gems that are using Octokit.rb</a>.
No problem.
The possibilites are endless.</p>
<h2 id="highlights">Highlights</h2>
<p>On github.com, we enjoy the context provided by code snippets and highlights in
search results.</p>
<p><a href="https://github.com/search?q=faraday+builder+repo%3Aoctokit%2Foctokit.rb&type=Code"><img src="https://f.cloud.github.com/assets/865/819651/959a4826-efb5-11e2-8af8-46c4a3857cdf.png" alt="code-snippet-highlighting"></a></p>
<p>We want API consumers to have access to that information as well. So, API
requests can opt to receive those
<a href="/v3/search#text-match-metadata">text fragments in the response</a>. Each fragment is accompanied by
numeric offsets identifying the exact location of each matching search term.</p>
<h2 id="preview-period">Preview period</h2>
<p>We’re making this new API available today for developers to
<a href="/v3/search/#preview-mode">preview</a>. We think developers are going to love it, but we want
to get your feedback before we declare the Search API “final” and
“unchangeable.” We expect the preview period to last for roughly 60 days.</p>
<p>As we discover opportunities to improve this new API during the preview period,
we may ship changes that break clients using the preview version of the API. We
want to iterate quickly. To do so, we will announce any changes here (on the
developer blog), but we will not provide any advance notice.</p>
<p>At the end of preview period, the Search API will become an official component
of GitHub API v3. At that point, the new Search API will be stable and suitable
for production use.</p>
<h2 id="what-about-the-old-search-api">What about the old search API?</h2>
<p>The <a href="/v3/search/legacy/">legacy search API</a> is still available. Many existing clients
depend on it, and it is not changing in any way. While the new API offers much
more functionality, the legacy search endpoints remain an official part of
GitHub API v3.</p>
<h2 id="take-it-for-a-spin">Take it for a spin</h2>
<p>We hope you’ll kick the tires and <a href="https://github.com/contact?form%5Bsubject%5D=New+Search+API">send us your feedback</a>. Happy
<del>searching</del> finding!</p>
tag:developer.github.com,2013-07-02:/changes/2013-07-02-rate-limit-reset/
When Does My Rate Limit Reset?
2013-07-02T05:00:00Z
2013-07-02T05:00:00Z
jasonrudolph
https://github.com/technoweenie
<p>Have you ever wondered when your <a href="/v3/#rate-limiting">rate limit</a> will reset back to its maximum value?
That information is now available in the new <code>X-RateLimit-Reset</code> response header.</p>
<pre class="terminal">
$ curl -I https://api.github.com/orgs/octokit
HTTP/1.1 200 OK
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1372700873
...
</pre>
<p>The <code>X-RateLimit-Reset</code> header provides a <a href="https://en.wikipedia.org/wiki/Unix_time">Unix UTC timestamp</a>, letting you know the exact time that your fresh new rate limit kicks in.</p>
<p>The reset timestamp is also available as part of the <code>/rate_limit</code> resource.</p>
<pre class="terminal">
$ curl https://api.github.com/rate_limit
{
"rate": {
"limit": 60,
"remaining": 42,
"reset": 1372700873
}
}
</pre>
<p>For more information on rate limits, be sure to check out the <a href="/v3/#rate-limiting">docs</a>.</p>
<p>If you have any questions or feedback, please <a href="https://github.com/contact?form%5Bsubject%5D=X-RateLimit-Reset">drop us a line</a>.</p>
tag:developer.github.com,2013-07-01:/changes/2013-07-01-feeds-api/
Feeds API
2013-07-01T05:00:00Z
2013-07-01T05:00:00Z
pengwynn
https://github.com/technoweenie
<p>Today we’re releasing a new <a href="/v3/activity/feeds/">Feeds API</a>, an easy way to list all the Atom
resources available to the authenticated user.</p>
<pre class="terminal">
curl -u defunkt https://api.github.com/feeds
{
"timeline_url": "https://github.com/timeline",
"user_url": "https://github.com/{user}",
"current_user_public_url": "https://github.com/defunkt",
"current_user_url": "https://github.com/defunkt.private?token=abc123",
"current_user_actor_url": "https://github.com/defunkt.private.actor?token=abc123",
"current_user_organization_url": "https://github.com/organizations/{org}/defunkt.private.atom?token=abc123",
"_links": {
"timeline": {
"href": "https://github.com/timeline",
"type": "application/atom+xml"
},
"user": {
"href": "https://github.com/{user}",
"type": "application/atom+xml"
},
"current_user_public": {
"href": "https://github.com/defunkt",
"type": "application/atom+xml"
},
"current_user": {
"href": "https://github.com/defunkt.private?token=abc123",
"type": "application/atom+xml"
},
"current_user_actor": {
"href": "https://github.com/defunkt.private.actor?token=abc123",
"type": "application/atom+xml"
},
"current_user_organization": {
"href": "https://github.com/organizations/{org}/defunkt.private.atom?token=abc123",
"type": "application/atom+xml"
}
}
}
</pre>
<p>If you have any questions or feedback, <a href="https://github.com/contact?form%5Bsubject%5D=Feeds%20API">please drop us a line</a>.</p>
tag:developer.github.com,2013-05-06:/changes/2013-05-06-create-update-delete-individual-files/
Create, update, and delete individual files
2013-05-06T05:00:00Z
2013-05-06T05:00:00Z
ymendel
https://github.com/technoweenie
<p>We’re following in the footsteps of GitHub.com’s ability to <a href="https://github.com/blog/143-inline-file-editing">edit</a> and
<a href="https://github.com/blog/1327-creating-files-on-github">create</a> files in your web browser. Starting today, the
<a href="/v3/repos/contents/">Repository Contents API</a> will let you easily <a href="/v3/repos/contents/#create-a-file">create</a>, <a href="/v3/repos/contents/#update-a-file">update</a>, and even
<a href="/v3/repos/contents/#delete-a-file">delete</a> individual files.</p>
<p>Happy editing!</p>
tag:developer.github.com,2013-05-06:/changes/2013-05-06-repository-stats/
Repository Statistics
2013-05-06T05:00:00Z
2013-05-06T05:00:00Z
Caged
https://github.com/technoweenie
<p>Today we’re happy to open our <a href="/v3/repos/statistics">Repository Statistics API</a> to everyone. We’re using
repository statistics to power <a href="https://github.com/github/linguist/graphs">our graphs</a>,
but we can’t wait to see what others can do with this information.</p>
<p>Starting today, these resources are available to you:</p>
<ul>
<li><strong><a href="/v3/repos/statistics/#get-contributors-list-with-additions-deletions-and-commit-counts">Contributors</a></strong></li>
<li><strong><a href="/v3/repos/statistics/#get-the-last-year-of-commit-activity-data">Commit Activity</a></strong></li>
<li><strong><a href="/v3/repos/statistics/#get-the-number-of-additions-and-deletions-per-week">Code Frequency</a></strong></li>
<li><strong><a href="/v3/repos/statistics/#get-the-weekly-commit-count-for-the-repo-owner-and-everyone-else">Participation</a></strong></li>
<li><strong><a href="/v3/repos/statistics/#get-the-number-of-commits-per-hour-in-each-day">Punch Card</a></strong></li>
</ul><p>Enjoy!</p>
tag:developer.github.com,2013-04-30:/changes/2013-04-30-improved-submodule-support-in-repository-contents-api/
Improved Support for Submodules in the Repository Contents API
2013-04-30T05:00:00Z
2013-04-30T05:00:00Z
jasonrudolph
https://github.com/technoweenie
<p>When you view a repository with a submodule on github.com, you get useful links and information for the submodule.</p>
<p><a href="/images/posts/submodule-links.png"><img src="/images/posts/submodule-links.png" alt="Repository Contents with Submodule"></a></p>
<p>Today we’re making that data available in the <a href="/v3/repos/contents/#get-contents">Repository Contents API</a>.</p>
<pre class="terminal">
curl https://api.github.com/repos/jquery/jquery/contents/test/qunit
{
"name": "qunit",
"path": "test/qunit",
"type": "submodule",
"submodule_git_url": "git://github.com/jquery/qunit.git",
"sha": "6ca3721222109997540bd6d9ccd396902e0ad2f9",
"size": 0,
"url": "https://api.github.com/repos/jquery/jquery/contents/test/qunit?ref=master",
"git_url": "https://api.github.com/repos/jquery/qunit/git/trees/6ca3721222109997540bd6d9ccd396902e0ad2f9",
"html_url": "https://github.com/jquery/qunit/tree/6ca3721222109997540bd6d9ccd396902e0ad2f9",
"_links": {
"self": "https://api.github.com/repos/jquery/jquery/contents/test/qunit?ref=master",
"git": "https://api.github.com/repos/jquery/qunit/git/trees/6ca3721222109997540bd6d9ccd396902e0ad2f9",
"carview.php?tsp=html": "https://github.com/jquery/qunit/tree/6ca3721222109997540bd6d9ccd396902e0ad2f9"
}
}
</pre>
<p>If you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=Submodules%20in%20Repository%20Contents%20API">support@github.com</a>.</p>
tag:developer.github.com,2013-04-30:/changes/2013-04-30-statuses-for-branches-and-tags/
Commit Statuses Now Available for Branches and Tags
2013-04-30T05:00:00Z
2013-04-30T05:00:00Z
foca
https://github.com/technoweenie
<p>Last week we announced <a href="https://github.com/blog/1484-check-the-status-of-your-branches">support for build statuses in the branches page</a>.
Now we are extending this to the API. The <a href="https://developer.github.com/v3/repos/statuses/#list-statuses-for-a-specific-ref">API endpoint for commit statuses</a>
has been extended to allow branch and tag names, as well as commit SHAs.</p>
<pre class="terminal">
curl https://api.github.com/repos/rails/rails/statuses/3-2-stable
</pre>
<p>Enjoy.</p>
tag:developer.github.com,2013-04-25:/changes/2013-04-25-deprecating-merge-commit-sha/
Deprecating a Confusing Attribute in the Pull Request API
2013-04-25T05:00:00Z
2013-04-25T05:00:00Z
jasonrudolph
https://github.com/technoweenie
<p>When you get the details for a Pull Request from the API, the
<a href="/v3/pulls/#get-a-single-pull-request">response</a> provides everything there is to
know about that Pull Request. In addition to the useful information provided in
the API response, the JSON also includes the <code>merge_commit_sha</code> attribute. This
attribute is a frequent source of misunderstanding, and we aim to remove the
confusion.</p>
<p>To help current API consumers, we’ve <a href="/v3/pulls/#mergability">documented the
attribute</a> for improved understanding.</p>
<p>To protect future API consumers from this confusion, we have
<a href="/#expected-changes">deprecated</a> the <code>merge_commit_sha</code> attribute, and we will
remove it in the next major version of the API.</p>
<p>As always, if you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=Deprecating%20merge_commit_sha">support@github.com</a>.</p>
tag:developer.github.com,2013-04-24:/changes/2013-04-24-user-agent-required/
User Agent now mandatory
2013-04-24T05:00:00Z
2013-04-24T05:00:00Z
pengwynn
https://github.com/technoweenie
<p>After an almost six week grace period, we’re now enforcing the <a href="/v3/#user-agent-required">User Agent
header</a> for all API requests. Most HTTP libraries (including cURL)
set this header by default. If you’re experiencing an increase in <code>403</code>
responses, be sure and check your code.</p>
<p>If you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=User%20Agent%20Requirement">support@github.com</a>.</p>
tag:developer.github.com,2013-03-01:/changes/2013-3-1-new-hookshot-coming/
New Hookshot Changes
2013-03-01T06:00:00Z
2013-03-01T06:00:00Z
technoweenie
https://github.com/technoweenie
<p>We are experimenting with changes to the “Hookshot” backend that powers service
hooks. There were some significant networking changes with the new cluster,
so there are some new IP whitelist rules for hooks:</p>
<ul>
<li>204.232.175.64/27</li>
<li>192.30.252.0/22</li>
</ul><p>These are in CIDR notation. They represent a significant range of GitHub
addresses, meaning this should be the last IP change for a while. Once this
cluster is activated and we shut the other cluster down, we will be removing
the other entries.</p>
<p>We are currently testing the new backend with all repositories in the GitHub
organization only, and expect to start testing it with user data next week.</p>
<p>This also means we should be able to start accepting <a href="https://github.com/github/github-services/pulls">GitHub Services pull
requests</a> very soon :)</p>
tag:developer.github.com,2013-02-14:/changes/2013-2-13-sortable-stars/
Sortable Stars in Repository Starring API
2013-02-14T06:00:00Z
2013-02-14T06:00:00Z
pengwynn
https://github.com/technoweenie
<p>As we <a href="https://github.com/blog/1410-sortable-stars">announced on the GitHub blog</a>, Stars now support sorting. The
Repository Starring API now supports <a href="/v3/activity/starring/#list-repositories-being-starred">two new parameters</a> when listing
Stars: <code>sort</code> and <code>direction</code>.</p>
<pre class="terminal">
curl https://api.github.com/users/defunkt/starred?sort=created&direction=asc
</pre>
<p>Enjoy.</p>
tag:developer.github.com,2013-02-13:/changes/2013-2-13-hookshot-load-balancer/
Hookshot Load balancer
2013-02-13T12:00:00Z
2013-02-13T12:00:00Z
technoweenie
https://github.com/technoweenie
<p>We had an issue with the Hookshot load balancer this morning, causing the
majority of hooks to flow to a single node only. This lead to massive queue
times. While fixing this, we’re putting the old Services backend in use.</p>
<p>This means the old IPs are back in use. Use this <a href="https://help.github.com/articles/what-ip-addresses-does-github-use-that-i-should-whitelist">Help guide</a>
if you already removed them from your firewall.</p>
tag:developer.github.com,2013-02-13:/changes/2013-2-13-hookshot-issues/
Some Hookshot Issues
2013-02-13T11:00:00Z
2013-02-13T11:00:00Z
technoweenie
https://github.com/technoweenie
<p>We turned Hookshot (our new GitHub Services backend) on yesterday. Things have
been pretty smooth, with one issue: Hooks going to other EC2 nodes come from
the private IP addresses of our nodes in the 10.<em>.</em>.* range.</p>
<p>If your web hook servers are on EC2 and are missing hooks from GitHub due to
an IP restriction, we recommend the following:</p>
<ol>
<li>Remove the IP white list.</li>
<li>Fall back to HTTPS and Basic Auth to restrict pushes to authorized senders only.</li>
</ol><p>We’re currently working on solving this problem. Hit up <a href="mailto:support@github.com">support@github.com</a>
if you have any questions.</p>
tag:developer.github.com,2013-02-05:/changes/2013-2-5-changes-to-services/
Upcoming Changes to GitHub Services
2013-02-05T06:00:00Z
2013-02-05T06:00:00Z
technoweenie
https://github.com/technoweenie
<p>We are finishing up a new GitHub Services backend, dubbed “Hookshot”, to
increase the speed and reliability of our delivered payloads. We are doing
what we can to make this a seamless transition for everyone. However, there
are a few notable changes.</p>
<ul>
<li>
<p>There is a new <a href="https://developer.github.com/v3/meta/">Meta API endpoint</a>
listing the current public IPs that hooks originate from.</p>
</li>
<li>
<p>We’re removing the AMQP service from GitHub. It hasn’t worked in quite some
time, and the code it uses doesn’t work in our background workers.</p>
</li>
<li>
<p>We’re also instituting a new guideline to improve the reliability and
maintainability of services in the future. As of today, all new services must
accept an unmodified payload over HTTP. Any service that does not will be
rejected. To see an example of an acceptable service, check out <a href="https://github.com/github/github-services/blob/master/lib/services/codeclimate.rb">Code Climate</a>.
Notice their service simply accepts HTTP POST from GitHub unmodified. For an
example of a service that won’t be accepted after today, check out <a href="https://github.com/github/github-services/blob/master/lib/services/campfire.rb">Campfire</a>. It
uses other Ruby gems and contains custom logic to transform the GitHub payload
to Campfire messages. Existing hooks will keep working (don’t worry 37signals, we
:heart: Campfire).</p>
</li>
</ul><p>We’re making these changes because we want to focus on the reliability of the
core Services backend for everyone. Maintaining custom logic and libraries for
over 100 services is taking too much of this focus away.</p>
tag:developer.github.com,2013-01-31:/changes/2013-01-31-user-agent-will-soon-be-mandatory/
User Agent mandatory from March 4th 2013
2013-01-31T06:00:00Z
2013-01-31T06:00:00Z
agh
https://github.com/technoweenie
<p>Following on from our <a href="https://developer.github.com/changes/2012-10-14-rate-limit-changes/">previous post</a>
about requiring requests to include a valid <a href="https://en.wikipedia.org/wiki/User_agent">User Agent header</a>
we will soon be changing our API servers to return HTTP 403
to any clients not providing a valid User Agent header.</p>
<p>We will be making this change on Monday, March 4th 2013.</p>
<p>Setting this helps us identify requests from you, and get in touch with people who are using
the API in a way which causes disruption to GitHub. Most HTTP libraries and tools like cURL
already provide a valid header for you, and allow you to customize it, so this will not require
many of our users to make any changes whatsoever.</p>
<p>If you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=User%20Agent%20Requirement">support@github.com</a>.</p>
tag:developer.github.com,2013-01-08:/changes/2013-01-08-new-user-scopes/
New User scopes
2013-01-08T06:00:00Z
2013-01-08T06:00:00Z
technoweenie
https://github.com/technoweenie
<p>We’ve added a <a href="https://developer.github.com/v3/oauth/#scopes">few new user scopes</a> for 3rd party applications that want very
specific user functionality. The <code>user:email</code> scope gives apps read-only access
to a user’s private email addresses. The <code>user:follow</code> scope lets a user
follow and unfollow other users.</p>
<p>This should help keep applications from requiring the <code>user</code> scope, which
can be potentially dangerous.</p>
<p>We also added a read-only endpoint to get a user’s public SSH keys.</p>
<pre><code>GET https://api.github.com/users/technoweenie/keys
</code></pre>
tag:developer.github.com,2012-12-10:/changes/2012-12-10-Diff-and-patch-media-types/
Diff and patch media types
2012-12-10T06:00:00Z
2012-12-10T06:00:00Z
pengwynn
https://github.com/technoweenie
<p>Starting today, you can get <code>.diff</code> and <code>.patch</code> content directly from the API for the following resources:</p>
<ul>
<li><a href="/v3/repos/commits/#get-a-single-commit">Commits</a></li>
<li><a href="/v3/repos/commits/#compare-two-commits">Commit comparisons</a></li>
<li><a href="/v3/pulls/#get-a-single-pull-request">Pull request</a></li>
</ul><p>Simply use the same resource URL and send either <code>application/vnd.github.diff</code> or <code>application/vnd.github.patch</code> in the <code>Accept</code> header:</p>
<pre><code>curl -H "Accept: application/vnd.github.diff" https://api.github.com/repos/pengwynn/dotfiles/commits/aee60a4cd56fb4c6a50e60f17096fc40c0d4d72c
diff --git a/tmux/tmux.conf.symlink b/tmux/tmux.conf.symlink
index 1f599cb..abaf625 100755
--- a/tmux/tmux.conf.symlink
+++ b/tmux/tmux.conf.symlink
@@ -111,6 +111,7 @@ set-option -g base-index 1
## enable mouse
set-option -g mouse-select-pane on
set-option -g mouse-select-window on
+set-option -g mouse-resize-pane on
set-window-option -g mode-keys vi
set-window-option -g mode-mouse on
# set-window-option -g monitor-activity off
</code></pre>
tag:developer.github.com,2012-12-09:/changes/2012-12-09-organization-repositories-results-now-paginate/
Pagination for Organization Repository lists now paginates properly
2012-12-09T06:00:00Z
2012-12-09T06:00:00Z
rick
https://github.com/technoweenie
<p><img src="https://github-images.s3.amazonaws.com/skitch/seger-turn-the-page-20121209-154956.png" alt=""></p>
<p>Improvements continue to the Organizations Repository listing endpoint.
Today we’re improving pagination so that it works as documented. Now
you can expect <code>Link</code> headers to navigate through the results space,
regardless of what you send in the <code>type</code> parameter.</p>
<p>The docs for Organization Repositories queries are still here:</p>
<ul>
<li><a href="/v3/repos/#list-organization-repositories">Organization Repositories</a></li>
</ul><p><strong>EDIT:</strong> <code>Link</code> headers are our preferred navigation technique.</p>
tag:developer.github.com,2012-12-08:/changes/2012-12-08-finding-source-and-fork-repos-for-organizations/
Finding sources and fork repositories for organizations
2012-12-08T06:00:00Z
2012-12-08T06:00:00Z
rick
https://github.com/technoweenie
<p>We’ve made a couple of changes today to the Organization repositories
listing to bring it a bit closer to the functionality of the GitHub.com
Organization repositories tab. We now let you retrieve repositories
which are forks of another repo, as well as those repositories which
are sources (not forks).</p>
<pre><code># Grab all fork Repositories for an Organization
curl "https://api.github.com/orgs/:org/repos?type=forks"
# Grab all source Repositories for an Organization
curl "https://api.github.com/orgs/:org/repos?type=sources"
</code></pre>
<p>Check out the docs for sorting and filtering options:</p>
<ul>
<li><a href="/v3/repos/#list-organization-repositories">Organization Repositories</a></li>
</ul>
tag:developer.github.com,2012-12-06:/changes/2012-12-06-create-authorization-for-app/
Create an OAuth authorization for an app
2012-12-06T06:00:00Z
2012-12-06T06:00:00Z
pengwynn
https://github.com/technoweenie
<p>The <a href="/v3/oauth/#oauth-authorizations-api">Authorizations API</a> is an easy way to create an OAuth
authorization using Basic Auth. Just POST your desired scopes and optional
note and you get a token back:</p>
<pre class="terminal">
curl -u pengwynn -d '{"scopes": ["user", "gist"]}' \
https://api.github.com/authorizations
</pre>
<p>This call creates a token for the authenticating user tied to a special “API”
OAuth application.</p>
<p>We now support creating tokens for <em>your own OAuth application</em> by passing your
twenty character <code>client_id</code> and forty character <code>client_secret</code> as found in
the settings page for your OAuth application.</p>
<pre class="terminal">
curl -u pengwynn -d '{ \
"scopes": ["user", "gist"], \
"client_id": "abcdeabcdeabcdeabcdeabcde" \
"client_secret": "abcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcde" \
}' \ '
https://api.github.com/authorizations
</pre>
<p>No more implementing the <a href="/v3/oauth/#web-application-flow">web flow</a> just to get a token tied to your
app’s rate limit.</p>
tag:developer.github.com,2012-12-04:/changes/2012-12-04-List-comments-for-repo/
Per-repository Review and Issue Comment listing
2012-12-04T06:00:00Z
2012-12-04T06:00:00Z
pengwynn
https://github.com/technoweenie
<p>You’ve always been able to grab all the commit comments for an entire
repository via the API, but to get Issue comments and Pull Request Review
Comments, you could only fetch the comments for a single Issue or Pull Request.</p>
<p>Today, we’re introducing two new methods to grab all Issue Comments and Review
Comments for a repository.</p>
<pre><code># Grab all Issue Comments
curl https://api.github.com/repos/mathiasbynens/dotfiles/issues/comments
# Grab all Review Comments
curl https://api.github.com/repos/mathiasbynens/dotfiles/pulls/comments
</code></pre>
<p>Check out the docs for sorting and filtering options:</p>
<ul>
<li><a href="/v3/issues/comments/#list-comments-in-a-repository">Issue comments</a></li>
<li><a href="/v3/pulls/comments/#list-comments-in-a-repository">Review comments</a></li>
</ul>
tag:developer.github.com,2012-11-29:/changes/2012-11-29-gitignore-templates/
Gitignore Templates API
2012-11-29T06:00:00Z
2012-11-29T06:00:00Z
pengwynn
https://github.com/technoweenie
<p>We recently <a href="/changes/2012-9-28-auto-init-for-repositories/">made it easy</a> to initialize a repository when you create
it <a href="/v3/repos/#create">via the API</a>. One of the options you can pass when creating a
repository is <code>gitignore_template</code>. This value is the name of one of the
templates from the the public <a href="https://github.com/github/gitignore">GitHub .gitignore repository</a>.</p>
<p>The <a href="/v3/gitignore/">Gitignore Templates API</a> makes it easy to list those templates:</p>
<pre><code>curl https://api.github.com/gitignore/templates
HTTP/1.1 200 OK
[
"Actionscript",
"Android",
"AppceleratorTitanium",
"Autotools",
"Bancha",
"C",
"C++",
...
</code></pre>
<p>If you’d like to view the source, you can also fetch a single template.</p>
<pre><code>curl -H 'Accept: application/vnd.github.raw' \
https://api.github.com/gitignore/templates/Objective-C
HTTP/1.1 200 OK
# Xcode
.DS_Store
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
*.xcworkspace
!default.xcworkspace
xcuserdata
profile
*.moved-aside
DerivedData
.idea/
</code></pre>
tag:developer.github.com,2012-11-27:/changes/2012-11-27-forking-to-organizations/
Forking to Organizations
2012-11-27T06:00:00Z
2012-11-27T06:00:00Z
technoweenie
https://github.com/technoweenie
<p>We made a slight change to the way you fork a repository. By default, you
can fork my repository through an HTTP POST to the repository’s fork resource.</p>
<pre><code>$ curl -X POST https://api.github.com/repos/technoweenie/faraday/forks
</code></pre>
<p>This repository forks to your personal account. However, there are cases when
you want to fork to one of your organizations instead. The previous method
required a <code>?org</code> query parameter:</p>
<pre><code>$ curl -X POST /repos/technoweenie/faraday/forks?org=mycompany
</code></pre>
<p>Query parameters on POST requests are unusual in APIs, and definitely
inconsistent with the rest of the GitHub API. You should be able to post a
JSON body like every other POST endpoint. Now, you can! Only, now we’re
calling the field <code>organization</code>.</p>
<pre><code>$ curl /repos/technoweenie/faraday/forks?org=mycompany \
-d '{"organization": "mycompany"}'
</code></pre>
<p>Don’t worry, we are committed to maintaining the legacy behavior until the next
major change of the GitHub API.</p>
tag:developer.github.com,2012-10-31:/changes/2012-10-31-gist-comment-uris/
Gist comment URIs
2012-10-31T05:00:00Z
2012-10-31T05:00:00Z
pezra
https://github.com/technoweenie
<p>The URIs of all gist comments are changing immediately. The new URI pattern for gist comments is <code>/gists/{gist-id}/comments/{id}</code>. (See <a href="/v3/gists/comments/">gist comments section of the docs</a> for more details.) This change is necessary because the auto-incremented ids of gist comments are easy to guess. This predictability allows anyone to view comments on private Gists with relative ease. Obviously, comments on private gists should be just as private as the gist itself.</p>
<p>Adding the gist id to the URI of comments makes it impossible, in practical terms, to guess that URI because the id of private gists are very large random numbers. This is, unfortunately, a breaking change but one that cannot be avoided because of the security implications of the current URIs. We apologize for the inconvenience.</p>
<p>We have also added a <code>comments_url</code> member to the Gist documents. The <code>comments_url</code> link provides access to the comments of a Gist in a way that will insulate clients from changes in the URI patterns used by the GitHub API. We are increasing our use of links in order to make changes such as this one less damaging to clients. We strongly encourage using <code>url</code> and <code>*_url</code> properties, where possible, rather than constructing URIs using the patterns published on this site. Doing so will result in clients that break less often.</p>
tag:developer.github.com,2012-10-26:/changes/2012-10-26-notifications-api/
Notifications API
2012-10-26T05:00:00Z
2012-10-26T05:00:00Z
technoweenie
https://github.com/technoweenie
<p>Now that the dust has settled around <a href="https://github.com/blog/1204-notifications-stars">Notifications and Stars</a>,
we’ve unleashed all that :sparkles: in a <a href="https://developer.github.com/v3/activity/notifications/">brand new API</a>. You can now
view and mark notifications as read.</p>
<h2 id="endpoint">Endpoint</h2>
<p>The core notifications functionality is under the <code>/notifications</code> endpoint.
You can look for unread notifications:</p>
<pre class="terminal">
$ curl https://api.github.com/notifications
</pre>
<p>You can filter these notifications to a single Repository:</p>
<pre class="terminal">
$ curl https://api.github.com/repos/technoweenie/faraday/notifications
</pre>
<p>You can mark them as read:</p>
<pre class="terminal">
# all notifications
$ curl https://api.github.com/notifications \
-X PUT -d '{"read": true}'
# notifications for a single repository
$ curl https://api.github.com/repos/technoweenie/faraday/notifications \
-X PUT -d '{"read": true}'
</pre>
<p>You can also modify subscriptions for a Repository or a single thread.</p>
<pre class="terminal">
# subscription details for the thread (either an Issue or Commit)
$ curl https://api.github.com/notifications/threads/1/subscription
# subscription details for a whole Repository.
$ curl https://api.github.com/repos/technoweenie/faraday/subscription
</pre>
<h2 id="polling">Polling</h2>
<p>The Notifications API is optimized for polling by the last modified time:</p>
<pre class="terminal">
# Add authentication to your requests
$ curl -I https://api.github.com/notifications
HTTP/1.1 200 OK
Last-Modified: Thu, 25 Oct 2012 15:16:27 GMT
X-Poll-Interval: 60
# Pass the Last-Modified header exactly
$ curl -I https://api.github.com/notifications
-H "If-Modified-Since: Thu, 25 Oct 2012 15:16:27 GMT"
HTTP/1.1 304 Not Modified
X-Poll-Interval: 60
</pre>
<p>You can read about the API details in depth in the <a href="https://developer.github.com/v3/activity/notifications/">Notifications documentation</a>.</p>
tag:developer.github.com,2012-10-24:/changes/2012-10-24-set-default-branch/
Set the default branch for a repository
2012-10-24T05:00:00Z
2012-10-24T05:00:00Z
pengwynn
https://github.com/technoweenie
<p>You can set the default branch for a repository to something other than ‘master’ from the GitHub repository admin screen:</p>
<p><img src="/images/posts/default-branch.png" alt="repo admin"></p>
<p>Now, you can update this setting via the API. We’ve added a <code>default_branch</code> parameter to the <a href="/v3/repos/#edit">Edit Repository method</a>:</p>
<pre class="terminal">
curl -u pengwynn \
-d '{"name": "octokit", "default_branch":"development"}' \
https://api.github.com/repos/pengwynn/octokit
</pre>
<p>If you provide a branch name that hasn’t been pushed to GitHub, we’ll gracefully fall back to <code>'master'</code> or the first branch.</p>
tag:developer.github.com,2012-10-17:/changes/2012-10-17-org-members-redirection/
Organization Members Resource Changes
2012-10-17T05:00:00Z
2012-10-17T05:00:00Z
pezra
https://github.com/technoweenie
<p>Requesting the <a href="/v3/orgs/members/index.html#members-list">member list</a> of an
organization of which you are not a member now redirects to the <a href="v3/orgs/members/index.html#public-members-list">public members
list</a>. Similarly, requests to
<a href="/v3/orgs/members/index.html#check-membership">membership check</a> resources of
an organization of which you are not a member are redirected to the equivalent
<a href="/v3/orgs/members/index.html#check-public-membership">public membership check</a>.
One exception to the latter case is that if you are checking about your own
membership the request is not redirected. You are always allowed to know what
organizations you belong to.</p>
<p>The changes where made to clarify the purpose of these various resources. The
<code>/orgs/:org/members</code> resources are intended for use by members of the
organization in question. The <code>/orgs/:org/public_members</code> resources are for
acquiring information about the public membership of organizations. If you are
not a member you are not allowed to see private membership information so you
should be using the public membership resources.</p>
<p>If you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=Org%20members%20API">support@github.com</a>.</p>
tag:developer.github.com,2012-10-14:/changes/2012-10-14-rate-limit-changes/
Rate limit changes for unauthenticated requests
2012-10-14T05:00:00Z
2012-10-14T05:00:00Z
pengwynn
https://github.com/technoweenie
<p>To ensure a high quality of service for all API consumers, we’ve reduced the
default rate limit for unauthenticated requests. To enjoy the default rate
limit of 5,000 requests per hour, you’ll need to
<a href="https://developer.github.com/v3/#authentication">authenticate</a> via Basic Auth
or OAuth. Unauthenticated requests will be limited to 60 per hour unless you
<a href="https://developer.github.com/v3/#unauthenticated-rate-limited-requests">include your OAuth client and
secret</a>.</p>
<p>We’ll soon require all requests to include a valid <a href="https://en.wikipedia.org/wiki/User_agent">User Agent
header</a>. Setting a
unique value for this header helps us identify requests and get in touch with
developers who are abusing the API. Most HTTP libraries, wrapper libraries, and
even cURL provide a valid header for you already and allow you to change it to
something unique to your application.</p>
<p>If you have any questions or feedback, please drop us a line at
<a href="mailto:support@github.com?subject=API%20Rate%20limit">support@github.com</a>.</p>
tag:developer.github.com,2012-09-28:/changes/2012-9-28-auto-init-for-repositories/
Initialize a repository when creating
2012-09-28T05:00:00Z
2012-09-28T05:00:00Z
pengwynn
https://github.com/technoweenie
<p>Today we’ve made it easier to add commits to a repository via the GitHub API.
Until now, you could <a href="/v3/repos/#create">create a repository</a>, but you would
need to initialize it locally via your Git client before adding any commits via
the API.</p>
<p>Now you can optionally init a repository when it’s created by sending <code>true</code>
for the <code>auto_init</code> parameter:</p>
<pre class="terminal">
curl -i -u pengwynn \
-d '{"name": "create-repo-test", "auto_init": true}' \
https://api.github.com/user/repos
</pre>
<p>The resulting repository will have a README stub and an initial commit.</p>
<p><img src="/images/posts/create-repo-init.png" alt="create repo screenshot"></p>
<h3 id="gitignore-templates">.gitignore templates</h3>
<p>Along with this change, you can set up your <code>.gitignore</code> template by passing
the basename of any template in the <a href="https://github.com/github/gitignore">GitHub gitignore templates
project</a>.</p>
<pre class="terminal">
curl -i -u pengwynn \
-d '{"name": "create-repo-test", "auto_init": true, \
"gitignore_template": "Haskell"}' \
https://api.github.com/user/repos
</pre>
<p>As the <a href="/v3/repos/#create">docs point out</a>, the <code>gitignore_template</code> parameter
is ignored if <code>auto_init</code> is not present and <code>true</code>.</p>
<p>If you have any questions or feedback, drop us a line at
<a href="https://github.com/c">https://github.com/contact</a>, <a href="mailto:support@github.com">support@github.com</a>, or
<a href="https://twitter.com/githubapi">@GitHubAPI</a>.</p>
tag:developer.github.com,2012-09-05:/changes/2012-9-5-watcher-api/
Upcoming Changes to Watcher and Star APIs
2012-09-05T05:00:00Z
2012-09-05T05:00:00Z
technoweenie
https://github.com/technoweenie
<p>We recently <a href="https://github.com/blog/1204-notifications-stars">changed the Watcher behavior</a> on GitHub. What
used to be known as “Watching” is now “Starring”. Starring is basically a way
to bookmark interesting repositories. Watching is a way to indicate that you
want to receive email or web notifications on a Repository.</p>
<p>This works well on GitHub.com, but poses a problem for the GitHub API. How do
we change this in a way that developers can gracefully upgrade their
applications? We’re currently looking at rolling out the changes in three
phases over an extended period of time.</p>
<h2 id="current-status">Current Status</h2>
<p>The current <a href="https://developer.github.com/v3/repos/starring/">Repository Starring</a> methods look like this:</p>
<ul>
<li>
<code>/repos/:owner/:repo/watchers</code> - A list of users starring the repository.</li>
<li>
<code>/users/:user/watched</code> - A list of repositories that a user has starred.</li>
<li>
<code>/user/watched</code> - A list of repositories the current user has starred.</li>
</ul><h2 id="phase-1-add-watchers-as-subscriptions">Phase 1: Add Watchers as Subscriptions</h2>
<p>This phase exposes Watchers as “Subscriptions”. This is to
keep from clashing with the legacy endpoints. This phase will happen
automatically and will not break your application until Phase 3 starts.</p>
<ul>
<li>
<code>/repos/:owner/:repo/subscribers</code> - A list of users watching the repository.</li>
<li>
<code>/users/:user/subscriptions</code> - A list of repositories that a user is watching.</li>
<li>
<code>/user/subscriptions</code> - A list of repositories the current user is watching.</li>
</ul><p>We’ll also add a copy of the legacy Watchers API in the new endpoint:</p>
<ul>
<li>
<code>/repos/:owner/:repo/stargazers</code> - A list of users starring the repository.</li>
<li>
<code>/users/:user/starred</code> - A list of repositories that a user has starred.</li>
<li>
<code>/user/starred</code> - A list of repositories the current user has starred.</li>
</ul><p>This is in place <em>now</em> with the current media type for the API:</p>
<pre><code>application/vnd.github.beta+json
</code></pre>
<p>If you care about your application not breaking, make sure all outgoing API
requests pass that value for the “Accept” header. You should do this now. This
can be verified by checking the <code>X-GitHub-Media-Type</code> header on all API
responses.</p>
<pre><code># Accesses a user's starred repositories.
curl https://api.github.com/user/watched \
-H "Accept: application/vnd.github.beta+json"
</code></pre>
<p>This Phase will be broken once Phase 3 starts. Phase 3 removes all support for
the “beta” media type, and makes the “v3” media type the implicit default
for API requests.</p>
<h2 id="phase-2-switch-watchers-api-endpoint">Phase 2: Switch <code>/watchers</code> API Endpoint</h2>
<p>The “watch” endpoints will now be a copy of the “subscription” endpoints. You
will have to use <code>/user/starred</code> to get a user’s starred repositories, not
<code>/user/watched</code>.</p>
<p>This requires a new media type value:</p>
<pre><code>application/vnd.github.v3+json
</code></pre>
<p>This is a breaking change from Phase 1. We will release this change in an
experimental mode first, letting developers gracefully upgrade their
applications by specifying the new media value for the Accept header.</p>
<pre><code># Accesses a user's watched repositories.
curl https://api.github.com/user/watched \
-H "Accept: application/vnd.github.v3+json"
</code></pre>
<h2 id="phase-3-remove-subscribers-api-endpoint">Phase 3: Remove <code>/subscribers</code> API Endpoint.</h2>
<p>This phase involves disabling the subscription endpoints completely. At this
point, you should be using the starring endpoints for starred repositories, and
the watch endpoints for watched repositories. No date has been set yet, but we
expect this to be <em>3-6 months</em> after Phase 2 is in place. This should give
developers enough time for a smooth upgrade path. If they use popular API
wrappers, the work will likely mostly be done for them.</p>
<p>Keep on passing the “v3” media type in your application, until the API has
another breaking change to make. If you can’t make the deadline for Phase 3,
just set the “beta” media type until we shut that down completely. It’s likely
that we will keep the old “beta” media type active for another month, like
the <a href="https://github.com/blog/1090-github-api-moving-on">last time</a> we terminated
old API functionality.</p>
<p>We look forward to assisting you through this transition. Hit us up at
<a href="https://github.com/c">https://github.com/contact</a>, <a href="mailto:support@github.com">support@github.com</a>, or
<a href="https://twitter.com/githubapi">@GitHubAPI</a>.</p>