GitHub Enterprise 2.2.0 April 29, 2015 Series notes · Download

New Features

With the new features added in GitHub Enterprise 2.2.0, you can:


Bug Fixes

Security Fixes

Repository storage changes

This release changes the way GitHub Enterprise stores repositories, which reduces disk usage by sharing Git objects between forks and improves caching performance when reading repository data. This is a major change, and has some implications you need to be aware of.

Changing the repository storage layout can take several hours if your instance contains many repositories. We're working on making this faster so if your instance contains more than 20,000 repositories (including gists and wikis) we do not recommend upgrading to GitHub Enterprise 2.2 until further notice. Everyone should now upgrade to GitHub Enterprise 2.2.2 or later, as the migration process has been made significantly faster.

You can check how many repositories you have using the Admin Stats API. For example, you can SSH into the VM and run the following command, then add together "total_repos", "total_wikis", and "total_gists":

curl -s

Before upgrading

As a precaution, before your upgrade you should take a backup-utils snapshot after putting the instance in maintenance mode. We also recommend taking a disk snapshot of the user data volume.


The upgrade process takes care of moving repository data from the existing storage layout to the new storage layout. If you have a large amount of repository data moving the data can take some time, so we recommend that you test the upgrade on a staging instance first. You can use the test upgrade to make an estimate of how long of a maintenance window you'll need for your production instance.

After upgrading, you may notice a large number of background jobs being processed. Each job is optimizing a repository for the new storage layout, but uses a high nice value, so should have minimal impact on performance. The jobs will be enqueued in the maint_localhost jobs queue, which may have a large backlog, but it's a dedicated queue and won't block other jobs from completing.

Repository backups

For compatibility with the new repository layout, you need to upgrade backup-utils to version 2.2.

The first update taken after you upgrade will be a full backup rather than an incremental backup. This means it will take more disk space and more time to complete. Subsequent backups will be incremental again.

Other implications of the change

Some customers routinely ran Git garbage collection on their repositories. The existing repository layout maps nicely to what you can see in the user interface, so you could easily find a repository on disk at /data/repositories/[owner]/[repository].git. This is no longer the case with the new repository layout, but it does let us be smarter about running garbage collection, so running it manually shouldn't be necessary.

So that they could be restored if necessary, deleted repositories were previously moved to the /data/repositories/__purgatory__ directory. This special area for archived repositories is no longer needed or used. Repositories are kept in their normal location until purged three months after being archived.

Please contact Enterprise Support if you have any questions about this change.

Snapshot and rollback recommendations

Due to the invasive changes in the repository disk layout in GitHub Enterprise 2.2, we strongly recommend reading the upgrade guide prior to upgrading your virtual machine. This provides information about using snapshots and rolling back to a pre-upgrade state in the event an upgrade fails or is interrupted.

Upcoming deprecation of authentication using GitHub OAuth

User authentication via GitHub OAuth is being deprecated and will be removed in a future feature release. It will be removed no sooner than November 2015.

GitHub Enterprise includes support for authenticating users via OAuth to accounts on because it provides a simple way to set up external authentication. However, after speaking with many customers, we've found that organizations commonly have other sources they want to use to automate identity and access management.

We want to focus on features that best meet the needs of our users, so we're planning to remove support for GitHub OAuth in a future feature release and focus on making ongoing improvements to other authentication methods like SAML and LDAP.

Note that this change will only affect user authentication via and not personal access tokens or OAuth applications added to your GitHub Enterprise instance.

Known Issues



The GitHub Team