Repairing Our Broken Specs Repository

Note: If you got this problem after running gem update, jump here to find a solution.

Unfortunately we've encountered a bug in libgit2 and we are going to have to force push into the Specs repository. (Also known as the ‘master’ spec repo.)

What does this mean for you?

Well, basically your CocoaPods setup is going to break. You are going to have to manually delete any local copies of the Specs repository and re-clone the new version of the Specs repository. You can do that with the following commands:

    $ sudo rm -fr ~/.cocoapods/repos/master
    $ pod setup
    

NOTE 1: If you have any local commits or changes to the Specs repository which are not merged, you should ensure you have a copy of them. I would recommend that you manually copy these changes over and re-commit them. You can fix your repository without deleting, however, this is not a simple process, so we are instead recommending that you delete your copy of the Specs repository and any forks of it.

NOTE 2: In case you are storing private podspecs in your clone of the Specs repository or you have a private spec repo that was forked from the Specs repository, this is a great time to clean that up by using private spec repositories The Proper Way. This way your private spec repository should never be affected by issues in other spec repositories.

If you really know what you’re doing and don’t want to re-download the complete repo, follow these instructions.

Why did this break?

The Specs repository has unfortunately broken due to a bug in libgit2 which powers GitHub's web editor. This has caused our git repository to become corrupt:

As fsck noted, it has duplicate entries, which is a violation of Git's object format. GitHub check objects as they are pushed into each fork; anyone who has built on top of the broken tree will have their push rejected, as they are trying to bring the broken object into their fork (as a result of it being reachable from their new commits).

We are looking into how this broken object got into the repository in the first place. At this point it looks like a web-edit […], that was then merged on the site via a pull request ([…] it looks like a bug in GitHub rather than any kind of user error). We're looking both into fixing the bug, but also into giving better protection to broken objects entering the repository (i.e. this is the exact sort of problem that the fsck-on-push checks are there to prevent, but they do not currently extend to web edits).

The only solution is to rewrite the history of the repository and force push the rewritten tree. Rolling out this fix basically means that all copies of the repository have to be reset. This can be a delicate process, so deleting and re-cloning is the safest and simplest way to do so.

Will this happen again?

There is a fix in the works to fix the bug in libgit2. This fixes a bug which would prevent libgit2 from corrupting a repository in this particular case.

GitHub are also working on putting checking measures in-place on the web-editor so that it wouldn't be possible to save a corrupt repository, and to prevent any similar problems in the future. (As is already the case when using git-push, which runs git-fsck on GitHub’s end.)

Acknowledgements

We would like to thoroughly thank the following people for their help in both investigating and resolving this matter. It is very much appreciated by all of us at CocoaPods HQ and shows the power of a (larger) community of people coming together.

• Jeff King (@peff)
• Roberto Tyley (@rtyley)
• Abizer Nasir (@Abizern)

We are very sorry for all time this issue takes away from our great early adopters and pod providers. We are very thankful for your patience and understanding while we work towards a smoothly functioning version 1 of CocoaPods and its architecture.

I got linked here after updating my gems, what to do?

This issue is being tracked down to an issue located in Psych. To fix it please use the following command: