What moves, what arrives changed, and what you lose.
Every forge’s migration page is a list of what it imports. The list that actually decides your move is the other one. So this page is per artifact, and the third column is the one written first.
Nothing here requires you to close the GitHub repository, and we do not think you should on day one. The pattern that works is a storefront: development moves, the old address keeps serving a maintained read-only mirror, and the README on it says where the work happens now.
Artifact by artifact
| Artifact | How it arrives | What is lost |
|---|---|---|
| Commits, branches, tags | Byte-identical. Every object arrives with its hash intact and every clone we serve is verified with a full strict fsck. | Nothing. |
| Signed commits and tags | Signatures are part of the object and travel with it. They verify with stock git on any clone. | We do not render a verified badge yet — there is no per-user key store here, so nothing on our side is checking the signature for you. |
| Contribution history | Computed from the history itself, so it renders as soon as the repository lands. Verify the addresses you have committed under and years of it appear at once. | Commits whose author address you cannot verify count for nothing. That is deliberate — see the open-source page for why. |
| Issues and comments | Bodies, authors, timestamps, labels, milestones, assignees, reactions and cross-references, in the order they were written. Old GitHub issue URLs resolve to their new home. | A commenter with no account here keeps a display name marked as coming from GitHub. We never silently attribute their words to a local account that merely looks similar. |
| Pull requests | Imported as issues, with the original URL recorded and a redirect so links in your history keep working. | The review threads do not become reviewable changes here. A merged PR’s head commits often no longer exist anywhere, so reconstructing patchsets from them is guesswork, and we would rather not guess about your history. |
| CI | A .weft/*.yml workflow runs on our runners on every push and every patchset, with a live log and a check that gates landing. CI you already run elsewhere posts its results back over the API instead, and gates the same way. | Your Actions workflows do not move over as they are. Ours is a small subset of that syntax — jobs, needs, matrices, shell steps — and uses: is refused with a line number rather than ignored, so anything built out of marketplace actions has to be rewritten as the commands it ran. That is still the largest cost of the move. |
| Releases and assets | Tags arrive with the history, so git describe and source tarballs built from a tag are unaffected. | Uploaded release binaries do not move. Keep publishing them where you publish them today; a download URL that already works is not worth breaking for tidiness. |
| Stars | The GitHub count is imported and rendered with its provenance stated — “60.3k on GitHub” — beside your count here. | The people behind them do not move. Nobody can transfer that, and a forge that quietly showed you the old number as its own would be lying to your next contributor. |
| Wiki, Projects, Discussions | A wiki is a git repository; mirror it like any other and it clones fine. | Projects and Discussions have no home here at all. Issues and labels cover the ground we chose to cover. |
| Funding links | Your existing funding file is read on import: Open Collective, Polar, Liberapay and Ko-fi links render on the repository and the profile. | There is no in-forge sponsor button, because we do not handle money. Every link points at the platform you already use. |
Keep the old address working
A project that vanishes from the address a hundred thousand READMEs point at has not migrated; it has disappeared. The pattern that works is the one the projects who did this successfully all converged on, and it has three parts.
Development moves
Contributors push here, review happens here, and the land queue here is what writes trunk. One writable copy — two is how histories diverge and how a maintainer ends up reconciling by hand on a Sunday.
GitHub becomes a mirror you maintain
Push trunk and tags back on every land, so every existing clone URL, every submodule pin and every package manager that resolves a git ref keeps resolving. Archiving the repository instead breaks all three.
The storefront says so
The GitHub README opens with where development happens and why, and issues there are closed with a pointer rather than left to rot. A stale issue tracker on the old address is the thing that actually costs you contributors.
The mirror direction Weft ships today is the inbound one — a read-only mirror of an origin you push to elsewhere, described in the mirror quickstart. Pushing back out to GitHub after each land is currently a step in your own CI: it is an ordinary git push --mirror to a remote you control, and we would rather tell you that than imply a button exists.
The order that goes wrong least
- Mirror first, decide later. Bring the repository over read-only while development carries on where it is. Nothing is committed to yet, the history is here, and you can see the contribution graph render.
- Verify your addresses. Every address you have ever committed under, including the ones from jobs you have left. This is what turns the graph from a partial count into your actual history.
- Import issues while the mirror runs. Read-only on both sides means there is no window where a comment can land in one place and not the other.
- Flip the write path on a quiet day. Point contributors here, set GitHub to a mirror you push, and rewrite the old README. This is the only irreversible-feeling step, and it is one afternoon.
- Leave both up for a release cycle. If it is going badly you will know inside one, and every clone URL still works the entire time.
How to leave us
The same page has to answer this, or the rest of it is marketing. Every repository here is standard git. Clone it with a stock client, or export it — one repository or an entire namespace — as plain git bundle files that any forge on earth will accept. There is no proprietary format holding your history, and no export queue to wait in.
Issues come out over the API in the shape they went in. The contribution graph does not need to be exported, because it was never data we held: it is derived from commits you already have.
What you would lose leaving is what you would lose leaving anywhere — the review threads and the intake decisions attached to changes that landed here. We would rather say that than claim a clean exit that does not exist.