Skip to content

New and Improved Service Hook Payloads

The service hook payloads now have the following new fields:

  • distinct=true for commits that are new to the repository
  • created=true for new branches
  • deleted=true for branch deletions
  • base=NAME for the base ref associated with a new branch

The campfire service hook now uses these new fields to improve messages sent to campfire:


Before, merges would replay existing commits that were merged into the branch:


Now, these distinct=false commits are ignored so only new commits show up:


This means that clean fast-forward merges no longer produce any campfire activity.

Forced Pushes


New Branches

New branches created via git push origin base:new show the name of the base branch:


Branches created locally with commits show what's new:


Deleted Branches


Note: Service hooks were not previously fired on branch deletions. CI and other endpoints that do not care about branch deletions can ignore deleted=true payloads.

Threaded Email Notifications

Over the weekend we rolled out a few changes to email notifications to better take advantage of your mail reader's ability to group messages into conversations and threads:

Here's what's changed:

  • Messages appear from the user that performed the action instead of from "GitHub" making it easier to scan and filter for messages from a specific person.

  • Subjects are now topic-focused: "Re: I found a bug in your project" instead of "jdoe commented on an issue". This causes Gmail to group messages properly and makes finding a discussion by topic a whole lot easier.

  • The Message-Id, References, and In-Reply-To headers are set for mail readers that group messages based on those attributes (pretty much everything except Gmail). GitHub notifications should take up much less real estate in your Inbox, and conversations can now be labeled, archived, and muted as a group.

These features should work similarly across a wide range of mail readers. If you notice a problem with yours, please leave a note here or open a ticket at

Reminder: you can customize email notification preferences for your account under the Notification Center.

Introducing the File Finder

Back when I started using TextMate, its cmd-T file finder completely changed the way I browse and read code. When I switched to Janus last year, it was only because I found the excellent Command-T plugin for vim.

These days, though, I find myself reading most new code in my browser on GitHub. And I really miss cmd-T.

So, I did the only thing that made sense: I added cmd-T to GitHub.

Try it out: just hit t on any repo's file or directory view.

Pull Request Diff Comments

That's right. They're here. Now you can comment directly on individual lines in the Diff attached to any Pull Request.

These things are smart. They keep their proper position, even after pushing additional changes to the same file.

Diff comment threads are also interleaved chronologically into the Discussion view along with a small diff excerpt for context. Great for coming up to speed on the evolution of a branch over time.

Leaving line comments is easy. Hover left of the line that you hate and hit the bubble.

Want to know more about how people are using Pull Requests? Check out our Futuristic Code Review feature page.

Improved Gist Search

One of my New Year's resolutions for this year is to make GitHub search awesome. Today I'm happy to announce that Phase One of this project is complete, in the form of a totally redone Gist search:

There are a few new features to notice.

  1. Matched snippets are shown and specific matches are highlighted in yellow.
  2. Code is syntax highlighted if a proper filetype was specified.
  3. Multiple matches in a single Gist file will be shown (up to a max of 3 snippets).

In addition, the reliability and comprehensiveness of the index are vastly improved and a ranking formula has been put in place that we can easily tweak over time to dial in the best results.

As I mentioned, this is only the beginning of the search improvements that you can look forward to over the coming months. I aim to make GitHub search your first and best choice when it comes to finding the projects, people, and code that you care about.

Announcing CodeConf 2011

GitHub is putting on a conference. You are invited.

screen shot 2015-04-23 at 9 50 40 am

Refreshed Pull Request Discussions

We just rolled out a slightly redesigned Pull Request discussion view. You can check it out on any pull request like this one on rack/rack.

This refresh opens up the layout and should make it eaisier to follow discussions in longer pull requests like this rails pull request.

Hope you guys enjoy!

Scheduled Maintenance Tonight at 22:00 PST

We will be performing scheduled maintenance tonight from 22:00 to 22:20 PST. During this window GitHub and all Git access will be entirely unavailable for a short period while we perform MySQL and Redis maintenance. GitHub Pages and GitHub Jobs will be unaffected.

Octocat Wallpapers for All

Now, GitHub is known for the awesome schwag we put on your backs. So how about some shwag for the much-loved electronic devices in your life?

Well, today's your lucky day! I'm proud to share with you some wallpapers of our beloved Octocat in its "Blacktocat" attire. Subtlety's the name of the game, hence the blackety-black, but they're easily colorable with a copy of Photoshop (or GIMP).

Get one or get 'em all and sport them on the devices of your choice today!

Git-powered wikis improved

Many of you already know about Gollum, the git-powered wiki system that we use for every GitHub Wiki. While the Wikis have been proven great for those that know git well, we want to involve everybody that may want to contribute to an open source project, whether or not they're good with git and code.

Because of this, you may have noticed that today we're pushing out an entire front-end rewrite of GitHub's Wiki system. While they may not look too different from the Wikis you're used to, the new Wiki interface has been designed to make adding new features easy. Even with this release, we've added a few improvements:

A brand new editor

wiki editor

The biggest change to the GitHub wikis is the completely new editor.

Functional support for most popular markup languages

The new editor has the capability to support every markup language that GitHub Wikis support. If you're a fan of Markdown, Textile, pod or RDoc, the function bar buttons (e.g. bold, italic, underline, etc.) will now work. We've even written brand new inline help for many of GitHub Wiki's supported markup languages.

The language definitions the editor uses are JSON-based and easy to edit. If you'd like us to support a markup language that we don't currently support, Gollum, GitHub's wiki software, is entirely open source -- fork our code and send us a pull request with changes that support your choice language.

Completely rewritten inline help

Inline help has also been completely rewritten for many of the editor's supported markup languages. Right now you might only see most of this help documentation in English, but our translators are already able to start working on the help for GitHub's other supported languages. If your markup language has inline help, a question-mark icon will appear in the editor's toolbar.

Inline footer and sidebar editing

GitHub Wikis have a little-documented ability for footers and sidebars, something which some of our git-based Wiki authors are familiar with. The new Wiki editor gives you limited web-based editing of the footers and sidebars you have on your site. Once you have created a footer or sidebar using the git access feature, you can edit it via the web interface.

Full-page preview

wiki preview page

The old Wiki editor allowed you to preview your content inline. Inline previewing doesn't really give you a full idea of what your page would appear like. Now, previews open in a new window or tab on a real Wiki page, giving you the ability to really see your changes as they would appear to a reader.

Revert capabilities

wiki history page

Before this release, the only way to solve the problem was to revert to an older version of a Wiki page was via the git command-line or manually editing the change via the web-based editor. Revert capabilities have now been added to the web interface. Want to change back to a version before a dumb edit you've made? Don't worry about opening a terminal window -- you can now fix it by selecting a commit and reverting all changes in the time range.

New permissions settings

wiki permissions

Before today, anybody could edit a wiki on a public repository. Now, repository owners have the ability to restrict editing to only those that are collaborators on that repository. If you'd like to use your Wiki for documentation but you don't want the world adding their own examples, simply check the box for this option on your Repository Administration page.

There's more in store

While we believe we're making a step in the right direction with the new UI, remember that the frontend was re-written for us to more easily add even more functionality to GitHub Wikis in the future. Be on the lookout for more improvements coming down the pipeline. If you'd like to use our git-backed wiki software on your site, clone Gollum and have fun.

Recent Services Interruptions

Here's a summary of the outages we encountered this week and what we're doing to prevent this from happening again.

Monday January 3rd

Monday marked the first "real" workday for most people in 2011. Our wonderful users all hopped online and got back to hacking. As North American work hours came around our Pacemaker application failed over one of our xen machines which happened to host our primary load balancer. This is something that happens really rarely and most of our users notice because the load balancer is the machine that everyone hits when accessing GitHub. This exposed a few problems in our infrastructure that we'll be addressing.

Our internal routing had issues that we hadn't experienced before due to our growing internal network. We specifically had problems with internal DNS resolution after the failover as well as routing certain traffic to some of our frontend machines.

New Relic was great in helping us diagnose this issue.

network outage

Something was taking WAY too long compared to how things normally look. Everything was essentially timing out.

Unfortunately it took us a little while to figure out the real issues were with networking. We know this can happen now and the team has a much better understanding over the networking overall.

We're now aware that under our current configuration, certain services on our load balancers must be located on different hosts to prevent this particular routing issue. We have a plan in place to reconfigure that part of our networking setup to remove the issue. In the meantime, we're also setting up a third load balancer to restore our n+1 redundancy.

During all of the networking insanity we had a fileserver, fs7, failover during this bumpy outage. We use a high availability setup for the fileservers, and they fail over a lot more often than you'd think. We kind of chalked it up to general insanity inside the cluster and our trusty sysadmin, Tim, went off to make sure we didn't have another day like Monday.

We had intermittent service between 8:30AM PST and about 3PM PST.

Tuesday January 4th

Around 7AM PST on Tuesday we started to notice high load and an abnormally high number of http connections. By 8AM fs7, the same machine with problems the previous day, had failed over. The failover machine is usually online within a few minutes but due to the high load it hobbled along for a little over an hour. Shortly after that it kernel panicked which required Tim to spend some quality time with it. We realized that the kernel the failed fileserver was running was older than most of the rest of our fileservers so we decided to upgrade it. This took us a little bit and service was restored on fs7 by 3PM PST. Keep in mind that this only impacted a subset of our customers but a second shaky day obviously isn't what we want for our users.

Everything was back to normal but two straight days of issues impacting one fileserver left us a little spooked and focusing hard on what was wrong with fs7 specifically. Everything seemed to corrolate around north american business hours starting in EST, so we camped out and waited for wednesday morning.

Wednesday January 5th

Wednesday we saw the heightened load start around 5AM PST and resulted in a bumpy two hours. The system went in and out of swap before swapping itself to death shortly after 7am PST.

06:58:01 AM kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
07:10:01 AM    124428  16347368     99.24   1195892   7180972   1036700     11868      1.13         8
07:11:01 AM     90832  16380964     99.45    865808   4479240   1036700     11868      1.13         8
07:12:01 AM     96648  16375148     99.41    205644    939236   1036676     11892      1.13        36
07:13:10 AM     81588  16390208     99.50     36040    104276         0   1048568    100.00      9632
07:14:10 AM     83004  16388792     99.50     29232    100256         0   1048568    100.00      3812
07:15:10 AM     81992  16389804     99.50      2324     67620         0   1048568    100.00      3212

You can see it die off in collectd graphs.


Once again fs7 failed over and this time it had a lot of queued requests to handle when the failover was promoted. As the failover came up its load stayed extremely high but started to settle after 20-30 minutes of hammering it. We were unhappy that it happened again, but we were glad that we'd avoided another prolonged outage.

Around 8:30AM PST we saw another burst of activity on the fileserver, luckily we were watching the system closely and kept the system in check. You can see the memory start to rise here.

stomp it

We noticed something happening on the system that never should though, dozens of 'git pack-objects' calls running. Normally Librato keeps these processes in check but something seemed to be ignoring this. We made it through the second onslaught and had time to really dig into what might be causing the issue.

We started looking into what networks were on the fileserver, I'm sure you recognize a few of them.

We were investigating whether or not this specific fileserver might be overloaded due to popular projects when something else popped up. Joe from Librato pointed us to some really awkward behavior we were seeing in system resource usage on the server. Something that we weren't managing with Librato really grew out of control during the times we saw service interruptions and high load.


Memory grew linearly from around 3PM PST the day before until 5am where it maxed out and eventually lead to the box swapping itself to death.

You can also see the virtual memory follow a similar trend here.


With this information we were able to quickly identify that the git-http service that's running on the fs servers was not under Librato's policy management. We've been slowly pushing more and more people to use git-http by default and we hadn't experienced such a spike in traffic as we've seen over the past few days. We put git-http into a Librato container and we had to wait for Thursday morning to really test it.

Problem Solved

This morning went smoothly. Librato kept all of our git-http processes in check despite another morning of enormous git-http traffic. We're excited to get back to work on making GitHub better, not keeping GitHub running. We're really sorry for any inconvenience our users experienced due to the insanity over the past few days. We hope this run down of the events gives our users some insight into how we handle problems. Having metrics around as many things as possible really helped us identify a difficult problem to diagnose.

A big thanks go out to Saj from Anchor for waking up in the middle of the night for three days straight to help us out with systems issues. Thanks to Joseph Ruscio for the Librato insight that revealed the real fix.

The Tree Slider

Those of you running recent versions of Safari, Chrome, or Firefox 4 may have noticed some changes to tree browsing on GitHub.

The new HTML5 History API (which really has nothing to do with HTML — it's a JavaScript API) allows us to manage the URL changes while CSS3 transitions handle the sliding. Permalinks are always maintained, your back button works as expected, and it's much faster than waiting for a full page load.

Basically we intercept your click, call pushState() to change the browser's URL, load in data with Ajax, then slide over to it.

When you hit the back button, an onpopstate handler is fired after the URL changes, making it easy to send you "back".

Want more? Check out the HTML History API Demo and MDC's Manipulating the browser history documentation. Facebook has blogged about their use of this stuff, and Flickr has been doing it for months on their lightbox view.

There's also some hot replaceState() action over on our new Features page and the Pull Requests dashboard.

We're still getting all the kinks out of the Tree Slider, but we hope you like it!

New uploader & downloads screen

Update: Uploads have been deprecated

Not too long ago we rolled out the one true downloads button, but unfortunately the Downloads page was still left unattended. Well, today we’re rolling out a totally new downloads page – including a completely rewritten uploader.

You can check out the new downloads screen on pages like brotherbard’s gitx fork.

The new uploader

Most importantly, we’ve completely rewritten the file uploader. So when you go to a repository that you have pushable access to, you’ll see a new interface.

There were a few significant updates:

  • The uploader actually works (yay!)
  • Upload multiple files at a time (you can select multiple files in the file dialog or click choose file multiple times)
  • Better error handling (no more ambiguous alerts)

What should you use the downloads section for?

The downloads section is a great place to put things that are related to your project, but not necessarily the code. Some examples:

  • PDF documents explaining the technology
  • Binary distributions of software
  • Minified versions of javascript files
  • PSD Mockups
  • SQL or data dumps

And don’t forget that you can automatically generate zip and tar.gz packages of your codebase by using git tag and they’ll show up on the downloads page.

All of your downloads. One big button.

Update: Uploads have been deprecated

A couple of weeks ago, downloads on GitHub were everywhere — we had the Download Source buttons, the Downloads tab, and, some clicks away, perhaps the download you were looking for. The old UI made downloading especially hard for those needing to grab binaries of GitHub-hosted projects, with many people mistakenly downloading the source instead. To solve this — and to (hopefully) increase downloading on GitHub — we recently consolidated our downloads into one big Downloads button.

So how do I download stuff now?

Every repository now has a big Downloads button in the repository description — check out the image below:

New downloads button

When you click on the new Downloads button, you'll be presented with a couple of options. You can download the source of the branch or commit you're on, the latest packaged downloads, or even some tagged downloads. This way, we try to surface the things that people are looking for in the majority of cases:

New downloads dialog

Of course, the old Downloads page still exists. Clicking the last link in the Download Packages list will take you to the full Downloads page. From there, you can download (or upload) as you have in the past.

Pull Requests 2.0

GitHub launched with a simple pull request system on day one. You've used it to send 200 thousand pull requests in just over two years. Now we're taking it to the next level with a re-imagined design and a slew of new tools that streamline the process of discussing, reviewing, and managing changes.

As of today, pull requests are living discussions about the code you want merged. They're our take on code review and represent a big part of our vision for collaborative development.

Know What You're Sending

Sending a pull request is simple. Browse to the branch or commit with your recent work and hit the Pull Request button. You'll be greeted by a brand new screen:

Pull requests are now fully revision aware and take into account not only what you would like pulled but also where you intend those changes to be applied. They even work when sending from and to the same repository, making pull requests just as useful in scenarios where a team is working out of a single shared repository as they are in the fork + pull model.

When you send a pull request, you're starting a discussion.

Some back and forth is typically required before a pull request is accepted. The maintainer needs clarification, or the change doesn't conform to the project's coding conventions, or maybe someone was able to take a concept 80% to completion and needs help working through the last bits.

The discussion view makes pull requests the best place to have these types of conversations. Anywhere. Here's why:

The discussion view presents all pull request related activity as it unfolds: comment on the pull request itself, push follow up commits, or leave commit notes - it's all interleaved into the discussion view as it happens.

Revision Aware

The discussion view is perfect for watching changes evolve over time, but it's equally important to know exactly what modifications would be made if the changes were accepted right now. The Commits and Files Changed tabs are quickly accessible and show the cumulative progress of the pull request:

Look familiar? It's a miniature compare view.

Visible, Linkable, Archived

Anyone with access can browse a repository's pull requests by visiting the repository's Network ⇢ Pull Requests page.

Every pull request has a URL so you can link to them. They're archived forever and indexed by search engines.

An Issue at heart

Pull requests are tightly integrated into GitHub Issues. When you see an[^] icon in the issues list, it means there's a pull request attached.

Don't use Issues? No problem. You still get awesome pull requests.

Pull Request Dashboard

The pull request dashboard gives a high level view of all pull requests across every repository you or your organization is involved with.

What are you waiting for?

Pull requests sent prior to today are not automatically imported into the new system. If you have outstanding requests, use them as an opportunity to try out revision aware pull requests today!

Something went wrong with that request. Please try again.