Submodule Display

We now detect and display submodules making it easy to see what other code is being referenced via our web interface.

If the submodule points to a repo on GitHub it will be automatically linked. If you hover over the short SHA1 for a few seconds you’ll see the submodule address and full SHA1 in a tooltip.

GitHub Shirts Now Available!

You asked for them and we listened. We now have two GitHub shirt designs for sale via rubyrags.com!

The one and only, classic “Fork You” shirt is sure to turn heads. Seriously, just ask anyone that has one.

And brand new, available for the first time ever is the “All Your Rebase” shirt. Be the first on your block to confuse your svn-holdout friends!

Both shirts are printed on high quality American Apparel t-shirts in Asphalt color. Don’t forget to write your GitHub username on the back in permanent marker.

Send in photos of you or your friends wearing GitHub tees and we’ll post them up on this very blog. You too can be GitHub Famous!

Pull Request Auto-Responder

We just rolled out a new feature that allows you to activate an auto-response to any pull requests you receive.

Here’s a few use cases that make this a pretty cool feature:

  • You use an external service to manage tickets and patches, so you setup an auto-responder that’ll PM the requester with the pertinent information (ideally, with a link).
  • You’re going on vacation for a couple of weeks and just want to let any requesters know you’ll be able to take care of their patches when you get back.
  • Someone forked your repo and you’re tired of maintaining it, so you setup an auto-responder to let people know that the other guy is the person they should be sending pull requests to.

You’ll see the link in your repo’s edit page:

Inline File Editing






(You must have write access to the repository.)

Test Your Service Hooks

Show Me the Money

There have been a fair amount of requests for this feature and we were happy to oblige. If you click the “Update Credit Card” link on your account page, there’s a new link show below that’ll show you what credit card we have on file.

Testing Post-Receive Hooks

You can now test post-receive hooks by viewing the “edit” page of your repository.

This’ll fire off a similar payload to the one your post-receive URL will receive on a commit. The GitHub Services can be tested this way as well.

New post-receive API is Live

The new post-receive API is live. The guide has been updated to reflect the change.

Let There Be Renaming

Repositories can be renamed via their edit page.

Users can be renamed via their account page.

That is all.

New Git Site

Everyone’s favorite Git magician, Scott Chacon, recently released an awesome new resource for everything Git: http://git-scm.com/

In addition to Scott’s Gitcasts, our new Guides homepage, and other existing Git resources, it’s becoming easier and easier to get into Git.

Revamping the Guides

In an effort to make everyone’s Git and GitHub experience a little easier, we’re currently working on overhauling our guides. The first step was to replace the existing guides homepage that just listed all of the guides to a page with much more organization. Thanks goes out to Tekkub for spearheading the effort.

Stay tuned as we’re currently working on a much larger Git resource site that should ease the pain of beginners and advanced Git folk alike.

Embedded Gists

Okay, this is obvious: you can now embed gists directly into your website, blog, project overview, myspace page, whatever.

I’ve personally wanted this for a long time. May your code forever outlive your blog.

Improved SSH Key Organization

The original ssh public key interface left a lot to be desired. It’s was bulky, unintuitive, and altogether a pain to manage if you had lots of public keys.

With any luck, we’ve solved all of those issues with our new interface:

You’re now able to assign a name to your keys as well as very quickly add, edit, and delete them. All without having to deal with a bunch of textareas littering the page. We hope you like it!

Here's the Gist of it

Pasting has become a huge part of our workflow. We use it daily, but find most paste tools slightly wanting. We’d love versioning. We’d love SSL on our private pastes. We’d love to fork existing pastes. And you know what, we’d love to push and pull our pastes using Git.

Well, say hello to Gist.

It’s all those things and will soon be more. We’ve been working hard on it and hope you like.

Scaling Lesson #23742

GitHub was created as a side project, but it seems to have struck a nerve and gained traction quickly. As such, a lot of the infrastructure decisions were made not figuring on this sort of growth:

One of the major pieces of the infrastructure is how we store the repositories. The way it was originally setup worked great for a while, but it wasn’t sustainable.

As an example, lets take my github-services repository. Here’s where it was stored prior to yesterday:

/our-shared-drive/pjhyett/github-services.git

Straight forward and simple, as well as having the added benefit of the repo being easily locatable in the file system if we needed to debug an issue.

That works well unless you have thousands of folders sitting in the same directory. GFS tried as best as it could, but with the amount of IO we do at GitHub writing to and reading from the file system, a change had to be made quickly.

After migrating last night, taking the same repository, this is where it’s currently stored:

/our-shared-drive/5/52/af/b5/pjhyett/github-services.git

Instead of every user sitting in one directory, we’ve sharded the repositories based on an MD5 of the username. A large change to be sure, but with some number crunching by our very own Tom Preston-Werner, he told me everyone on the planet can sign up twice and we still won’t have to change the way we shard our repositories after this.

Another interesting point worth mentioning is the first directory, ‘5’, was setup specifically so we could add multiple GFS mounts (we currently use just one) using a simple numbering system to help scale the data when we start bumping up against that wall again.

Now, the question you may all be asking is why we didn’t do this from the beginning. The simple answer is it would have taken more time and prevented us from launching when we did. We could have spent a couple of extra weeks in the beginning figuring out and preventing bottlenecks, but the site may not have taken off and then we would have built a scalable site that three people use.

Truth be told, it’s a great problem to have, and the site is humming along smoothly now. Now we can get back to doing fun things like building new features for you guys and gals. Keep an eye out for the big one we’re launching next week!