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?

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.

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: