forked from google/developer.github.com
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathchanges.atom
More file actions
765 lines (660 loc) · 39.3 KB
/
Copy pathchanges.atom
File metadata and controls
765 lines (660 loc) · 39.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>http://developer.github.com/</id>
<title>GitHub API Changes</title>
<updated>2013-03-01T06:00:00Z</updated>
<link rel="alternate" href="http://developer.github.com/" />
<link rel="self" href="http://developer.github.com/changes.atom" />
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<entry>
<id>tag:developer.github.com,2013-03-01:/changes/2013-3-1-new-hookshot-coming/</id>
<title type="html">New Hookshot Changes</title>
<published>2013-03-01T06:00:00Z</published>
<updated>2013-03-01T06:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-3-1-new-hookshot-coming/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-02-14:/changes/2013-2-13-sortable-stars/</id>
<title type="html">Sortable Stars in Repository Starring API</title>
<published>2013-02-14T06:00:00Z</published>
<updated>2013-02-14T06:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-2-13-sortable-stars/" />
<content type="html"><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&amp;direction=asc
</pre>
<p>Enjoy.</p></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-02-13:/changes/2013-2-13-hookshot-load-balancer/</id>
<title type="html">Hookshot Load balancer</title>
<published>2013-02-13T12:00:00Z</published>
<updated>2013-02-13T12:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-2-13-hookshot-load-balancer/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-02-13:/changes/2013-2-13-hookshot-issues/</id>
<title type="html">Some Hookshot Issues</title>
<published>2013-02-13T11:00:00Z</published>
<updated>2013-02-13T11:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-2-13-hookshot-issues/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-02-05:/changes/2013-2-5-changes-to-services/</id>
<title type="html">Upcoming Changes to GitHub Services</title>
<published>2013-02-05T06:00:00Z</published>
<updated>2013-02-05T06:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-2-5-changes-to-services/" />
<content type="html"><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="http://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></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-01-31:/changes/2013-01-31-user-agent-will-soon-be-mandatory/</id>
<title type="html">User Agent mandatory from March 4th 2013</title>
<published>2013-01-31T06:00:00Z</published>
<updated>2013-01-31T06:00:00Z</updated>
<author>
<name>agh</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-01-31-user-agent-will-soon-be-mandatory/" />
<content type="html"><p>Following on from our <a href="http://developer.github.com/changes/2012-10-14-rate-limit-changes/">previous post</a>
about requiring requests to include a valid <a href="http://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></content>
</entry>
<entry>
<id>tag:developer.github.com,2013-01-08:/changes/2013-01-08-new-user-scopes/</id>
<title type="html">New User scopes</title>
<published>2013-01-08T06:00:00Z</published>
<updated>2013-01-08T06:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2013-01-08-new-user-scopes/" />
<content type="html"><p>We’ve added a <a href="http://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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-12-10:/changes/2012-12-10-Diff-and-patch-media-types/</id>
<title type="html">Diff and patch media types</title>
<published>2012-12-10T06:00:00Z</published>
<updated>2012-12-10T06:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-12-10-Diff-and-patch-media-types/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-12-09:/changes/2012-12-09-organization-repositories-results-now-paginate/</id>
<title type="html">Pagination for Organization Repository lists now paginates properly</title>
<published>2012-12-09T06:00:00Z</published>
<updated>2012-12-09T06:00:00Z</updated>
<author>
<name>rick</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-12-09-organization-repositories-results-now-paginate/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-12-08:/changes/2012-12-08-finding-source-and-fork-repos-for-organizations/</id>
<title type="html">Finding sources and fork repositories for organizations</title>
<published>2012-12-08T06:00:00Z</published>
<updated>2012-12-08T06:00:00Z</updated>
<author>
<name>rick</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-12-08-finding-source-and-fork-repos-for-organizations/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-12-06:/changes/2012-12-06-create-authorization-for-app/</id>
<title type="html">Create an OAuth authorization for an app</title>
<published>2012-12-06T06:00:00Z</published>
<updated>2012-12-06T06:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-12-06-create-authorization-for-app/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-12-04:/changes/2012-12-04-List-comments-for-repo/</id>
<title type="html">Per-repository Review and Issue Comment&nbsp;listing</title>
<published>2012-12-04T06:00:00Z</published>
<updated>2012-12-04T06:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-12-04-List-comments-for-repo/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-11-29:/changes/2012-11-29-gitignore-templates/</id>
<title type="html">Gitignore Templates API</title>
<published>2012-11-29T06:00:00Z</published>
<updated>2012-11-29T06:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-11-29-gitignore-templates/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-11-27:/changes/2012-11-27-forking-to-organizations/</id>
<title type="html">Forking to Organizations</title>
<published>2012-11-27T06:00:00Z</published>
<updated>2012-11-27T06:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-11-27-forking-to-organizations/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-10-31:/changes/2012-10-31-gist-comment-uris/</id>
<title type="html">Gist comment URIs</title>
<published>2012-10-31T05:00:00Z</published>
<updated>2012-10-31T05:00:00Z</updated>
<author>
<name>pezra</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-10-31-gist-comment-uris/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-10-26:/changes/2012-10-26-notifications-api/</id>
<title type="html">Notifications API</title>
<published>2012-10-26T05:00:00Z</published>
<updated>2012-10-26T05:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-10-26-notifications-api/" />
<content type="html"><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="http://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="http://developer.github.com/v3/activity/notifications/">Notifications documentation</a>.</p></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-10-24:/changes/2012-10-24-set-default-branch/</id>
<title type="html">Set the default branch for a repository</title>
<published>2012-10-24T05:00:00Z</published>
<updated>2012-10-24T05:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-10-24-set-default-branch/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-10-17:/changes/2012-10-17-org-members-redirection/</id>
<title type="html">Organization Members Resource Changes</title>
<published>2012-10-17T05:00:00Z</published>
<updated>2012-10-17T05:00:00Z</updated>
<author>
<name>pezra</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-10-17-org-members-redirection/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-10-14:/changes/2012-10-14-rate-limit-changes/</id>
<title type="html">Rate limit changes for unauthenticated requests</title>
<published>2012-10-14T05:00:00Z</published>
<updated>2012-10-14T05:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-10-14-rate-limit-changes/" />
<content type="html"><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="http://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="http://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="http://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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-09-28:/changes/2012-9-28-auto-init-for-repositories/</id>
<title type="html">Initialize a repository when creating</title>
<published>2012-09-28T05:00:00Z</published>
<updated>2012-09-28T05:00:00Z</updated>
<author>
<name>pengwynn</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-9-28-auto-init-for-repositories/" />
<content type="html"><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></content>
</entry>
<entry>
<id>tag:developer.github.com,2012-09-05:/changes/2012-9-5-watcher-api/</id>
<title type="html">Upcoming Changes to Watcher and Star APIs</title>
<published>2012-09-05T05:00:00Z</published>
<updated>2012-09-05T05:00:00Z</updated>
<author>
<name>technoweenie</name>
<uri>https://github.com/technoweenie</uri>
</author>
<link rel="alternate" href="http://developer.github.com/changes/2012-9-5-watcher-api/" />
<content type="html"><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="http://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></content>
</entry>
</feed>