The GitHub Blog

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:

(You must have write access to the repository.)

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.

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.

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

Repositories can be renamed via their edit page.

Users can be renamed via their account page.

That is all.

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.

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.

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.

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!

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.

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!

Files in your repository are now formatted same as the README. This means if you have a file with a .markdown extension, for example, it’ll show up all pretty-like.

Enjoy. (Our Git-powered wiki is coming soon…)

Over the past several weeks I’ve been working on a secret Erlang project that will allow us to grow GitHub in new and novel ways. The project is called egitd and is a replacement for the stock git-daemon that ships with git. If you’re not familiar, git-daemon is what has, until today, served all anonymous requests for git repositories. Any time you used a command like git clone git://github.com/user/repo.git you were being served those files by git-daemon.

The reason we need egitd is for flexibility and power. We need the flexibility to map the repo name that you specify on the command line to any disk location we choose. git-daemon is very strict about the file system mappings that you are allowed to do. We also need it so that we can distinguish and log first-time clones of repos. Keep an eye out (down the road) for statistics that show you exactly how many times your public repo has been cloned!

Another benefit of coding our own git server is enhanced error messages. I can’t even begin to tell you how many people have come to us complaining about the following error which is caused by trying to push to the public clone address:

fatal: The remote end hung up unexpectedly 

With egitd we can inject reasonable error responses into the response instead of just closing the connection and leaving the user bewildered. Behold!

fatal: protocol error: expected sha/ref, got '
*********'

You can't push to git://github.com/user/repo.git
Use git@github.com:user/repo.git

*********'

Still a little crufty, but until we can get something useful into core git, it’s the best we can do and should help many people as they learn git and get over some of the confusing aspects.