The GitHub Blog

I’ve just added a small diff enhancement that will help you determine what changed in one line diff sections. By highlighting the specific changes, you can now see at a glance what those little changes were in otherwise very similar lines of code.

Ari Lerner has a blog post about keeping your site as fresh as your code. How? By showing off recent commits.

See it in action on the poolparty website:

Nice. Anyone have a JavaScript version?

One of the slowest things you can do in Ruby is shell out to the operating system. As a contrived example, let’s open an empty file 1,000 times:

>> require 'benchmark'
>> `touch foo`
>> Benchmark.measure { 1000.times { `cat foo` } }.total
=> 4.51
>> Benchmark.measure { 1000.times { File.read('foo') } }.total
=> 0.04

The difference is clear – the very act of shelling out is expensive. And while 1,000 may seem high, we have plenty of content on GitHub with 30+ shell calls per page. It starts to add up.

The Problem with Grit

Our Grit library was written as an API to the git binary using, you guessed it, shell calls. In the past few weeks, as the site became slower and less stable, we knew we had to begin rewriting parts of our infrastructure. Response times and memory usage were both spiking. We began seeing weird out of memory errors and git segfaults.

Scott Chacon had been working on a pure Ruby implementation of Git for some time, which we’d been watching with interest. Instead of shelling out and asking the git binary for information, Scott’s library understands the layout of .git directories and uses methods like File.read to procure the requested information

Over the past few weeks we’ve been working with Scott to integrate his library into GitHub while he adds features and improves performance. Last night we rolled out a near-finished version of Scott’s library.

The result? Sweet, sweet speed.

Yep, we cut our average response time in half. (Lower numbers are better.)

Open Source

Scott will soon be merging the changes he made for us into his Grit fork. As a result, expect to see other Ruby-based Git hosting sites speed up in the next few weeks as they integrate the code we wrote.

We’re interested in funding the development of other Git related open source projects. If you’re working on something awesome that will drive Git adoption, please send us an email.

Future Enhancements

We’re still working to improve our architecture. As we roll out more changes, you’ll see them here. Everyone loves scaling.

The Download button is now supercharged. It gives you the option to download a Zip version of the repository and suggests other downloads – recent tags, basically – giving people have a chance to download your version’d releases.

After open sourcing the GitHub services code, we’ve been just floored with the number of pull requests for adding tons of functionality.

We launched the service hooks with just Campfire and Lighthouse and now we support Basecamp, Campfire, CIA.vc, Irc, Email, FogBugz, Jabber, Lighthouse and Twitter!

You can setup these services up by clicking ‘Service Hooks’ under the ‘Admin’ tab for the repositories you own.

Thanks again to the following people (if I’ve forgotten you, please let me know)

• Blake Mizerany
• Brandon Keepers
• Christian Neukirchen
• El Draper
• Florian Frank
• John Nunemaker
• John Reilly
• Jorge Bernal
• Luke Redpath
• Noah (ngage)
• Sean O’Brien
• Tekkub Stoutwrithe
• W. Andrew Loe III

We just rolled out our new and improved homepage. Here’s a taste.

Logged in users can hit http://github.com/home to view it in all its glory.

Update: Added http://github.com/home links.

It’s here for the faceboxes – I’m so sick of seeing people guess wrong about the formatting. Really, it makes me sad.

Coming soon everywhere else.

Now that it’s so easy to install gems, we figured that you should know when a repository offers a gem install.

So, that’s what we did:

If you see a ruby icon sitting in a repository’s detail box, it means they’ve checked the “RubyGem” option, and when you click on it, it’ll pop open a box telling you how to install it.

We’re working on some awesome new visualizations and statistics here at GitHub. While they’re not quite ready to roll out, there is one chart I wanted to share.

These are the top 10 languages stored on GitHub, based on some simple heuristics. Forks are not counted – only unique code.

For the folks trying to install a RubyGem via GitHub prior to yesterday’s release, you’d get the all too familiar “Updating metadata for 563 gems…” every time.

Well no more, thanks to a massive effort by Eric Hodel. Not only are the issues with adding multiple sources fixed, but the indexing has been fixed such that gem installs are basically instantaneous now.

Do yourself a favor and run the following commands if you’re a Ruby guy/gal.

$ sudo gem update --system
$ gem sources -a http://gems.github.com

You’re now able to install gems from GitHub directly without specifying the source, just like you would if you were installing them from RubyForge.

$ sudo gem install defunkt-github

That’s all there is to it, thanks Eric!

You can now clone public repositories hosted on GitHub over HTTP. This is very slow and should only be used if the git port (9418) is blocked due to a firewall or other tomfoolery.

Try it out:

git clone http://github.com/defunkt/facebox.git

If you’re a Ruby on Rails user, you can now install plugins without Git installed on your machine. This means your loyal blog readers stuck in the past don’t need Git to benefit from your Ruby wizardry.

Try it out:

./script/plugin install http://github.com/defunkt/cache_fu.git

Site feel slow? See a weird SSH message? Have a strange feeling in your gut? Wonder no longer – check out the GitHub Status Blog to see service related news about your favorite Git host.

Update: We’ve discontinued this feature.

Alliteration is fun isn’t it? Our friends at Pledgie busted out their css wizardry to restyle your project’s profiles to give them a more consistent feel with our site.

I predict y’all will make a million dollars on your open source projects now. Prove me wrong.

Before today, when you pushed your gemspec to GitHub the only way you knew whether or not your gem built successfully is if it showed up on our server. Not optimal, we know.

Now, when your gem isn’t built properly we’ll send the repository owner a private message with the error. Something like this:

Hopefully this will help you debug your gem-building woes.

We’ve just rolled out a search box on every repository that allows you to search by a number of criteria.

As always, your feedback how we can tweak the search to make it better is appreciated.

To kick this feature off right, post your favorite search in the comments.