What a git clone misses: pull request reviews, issues and discussions

What does a git clone actually copy?#

A git clone copies the repository's object database and references: every commit reachable from the branches and tags it fetches, with authors, timestamps, commit messages and the full file tree at each point. That is the complete history of the code as git records it.

Git knows nothing about the conversation around the code. A pull request is a platform feature that points at two branches and stores comments, approvals and status checks in the platform's own database. GitHub, for example, exposes the commits behind each pull request as special references that can be fetched, but those references carry code only, never the discussion.

A normal clone also skips some things for git's own reasons. Local hooks and repository configuration are not copied, and branches deleted after merging are gone unless their commits are reachable from something that remains.

In the repository versus on the platform#

The repository holds what changed; the platform holds why it changed, who agreed and what was argued along the way. A backup that keeps only the first half keeps the answers and loses the working.

Squash merges deserve attention. When a pull request is squashed, the repository keeps one commit, while the individual commits, the review rounds and the back-and-forth that shaped the final change remain only on the platform.

Why the platform half is the valuable half#

The platform half is the valuable half because it records engineering judgment. A diff shows the final change; the review thread shows the reviewer who spotted a race condition, the alternative that was rejected and the test added because of it.

That record matters for continuity when teams change, for diligence when a company is acquired, and for AI developers building and evaluating coding assistants, who look for linked chains of issue, pull request, review and merge. Commit messages rarely carry the same depth, and squash merges often reduce them to a one-line summary.

The links are part of the value. A cross-reference from an issue to the pull request that closed it, and from that pull request to the release that shipped it, turns separate records into a chain. Exports that drop timeline events or collapse authors into one importer account break those chains, so confirm that cross-references survive before anyone deletes the source.

How to export pull requests, reviews and issues#

Pull requests, reviews and issues are exported through the hosting platform's API or its migration and export features. GitHub, GitLab and Bitbucket all provide APIs, and the larger platforms also offer project or organization exports built for migrations; check current documentation for exactly what each one includes.

The packaged exports have limits worth knowing. GitHub documents an organization migration archive, generated through the API, that is designed for import into GitHub Enterprise Server and needs owner permissions on the source repositories and a token with the repo and admin:org scopes. GitLab's project file export includes issues with comments, merge requests, labels, milestones, releases and wikis, but GitLab says these files should not be used as backups because not every item is exported, and only the latest diff version and latest pipeline of each merge request remain visible after import. For full review history, a scripted API export is the safer copy.

Store the output as JSON keyed by repository and pull request or issue number, next to a mirror clone of each repository. With both halves keyed to commit IDs, the history can be reassembled on any platform later.

• 1List every repository, including archived ones, and note which have issues, wikis and discussions enabled.
• 2Pull pull requests with state, author, dates, base and head branches, merge commit and linked issues.
• 3Pull reviews and review comments with file path, line position, commit ID and reply threads.
• 4Pull issues with comments, labels, assignees, milestones and timeline events such as cross-references.
• 5Clone wikis stored as separate repositories, and export discussions where they are enabled.
• 6Download release notes and assets, and save CI logs still inside the platform's retention.
• 7Save a user map from platform usernames and IDs to people, including former employees.

Which export route fits your situation?#

The right export route depends on whether you are moving platforms, closing an account or building a long-term archive. Most teams combine a mirror clone with an API export, and add a platform importer only when the destination supports one.

Illustrative: a field service software company consolidating code hosting#

Illustrative: a fictional field service software company acquires a smaller scheduling product. The acquired team used a different code host, and the CTO plans to move its repositories into the parent company's organization and close the old account.

The first plan is a mirror clone of each repository. A senior engineer points out that the acquired product's most useful history, years of review threads on its routing engine and the issues behind each fix, would not survive. The team exports pull requests, reviews, review comments and issues through the old platform's API, saves a user map, and stores the JSON next to the mirrors in the parent company's archive.

The repositories move cleanly, and the review history stays searchable by commit ID. When leadership later considers licensing engineering records, the review threads and linked issues are already in one place, ready for a secrets scan and a rights check.

How SourceX handles engineering review history#

SourceX handles engineering review history as its own record family, separate from source code. Through the SourceX five-step transaction (Supply, Rights, Preparation, Approval and Delivery), the fit check uses metadata such as platforms, repository counts, years of history and whether pull requests link to issues, with no code shared.

Before any delivery, Preparation removes secrets, credentials and personal details, and the Rights review excludes customer-owned code and checks open source licenses. The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for the package.