A dead code-hosting site can leave behind a perfectly usable copy of the software and still lose half the story.
The obvious thing to save is the source tree: the files that compile into the program. But a repository can also contain years of commits, branches, tags, issue reports, wiki pages, release downloads, contributor names, timestamps, and discussions explaining why some ugly-looking line of code exists in the first place. That surrounding history is often what makes an old project understandable.
Google Code is a useful example because its shutdown was unusually well preserved. The hosting service was turned down in early 2016, but Google left behind the Google Code Archive, a read-only collection that reports more than 1.4 million projects, 1.5 million downloads, and 12.6 million issues.
That is the good version of a shutdown.
A repository is a timeline, not a folder
If all you preserve is the latest source snapshot, you can still read the program. What you cannot do is reliably reconstruct how it got there.
A Git, Mercurial, or Subversion repository may reveal when a feature appeared, who changed it, which release branch contained a fix, and whether a suspicious-looking file was temporary or intentional. Tags can connect code to a published release. Commit messages can explain design choices that were never documented anywhere else.
Then there are the things version control does not normally contain. Bug trackers may include reproduction steps and hardware details. Wiki pages may be the only installation manual. Release downloads can contain compiled binaries, sample data, or tools that were never checked into source control.
Google’s archive schema makes the separation unusually explicit: project metadata, wiki listings, issue summaries, commit summaries, downloads, individual issues, and source archives are stored as different objects. That is the preservation lesson. Copying the repository alone does not automatically save everything the hosting platform knew about the project.
Migration needs more than git clone
For Git projects, a mirror clone can preserve branches, tags, and repository objects. It does not preserve GitHub issues, pull requests, project boards, release notes, or externally hosted downloads unless those are exported separately. Other hosting systems have their own combinations of repository data and platform-specific records.
A complete rescue therefore needs an inventory. Save the repository. Export issue trackers and wikis. Download release artifacts. Preserve project descriptions and links. Record the original URL structure when possible so old references can be mapped to the surviving copy.
Even Google Code’s unusually thorough archive has limits. It is read-only, and resurrecting a project elsewhere still requires someone to interpret the preserved pieces and rebuild a working development environment.
When a code host closes, the question is not merely whether the source survived. The better question is how much of the project’s memory survived with it.