Migrating to neosource
Moving a project to neosource is not one operation. Code, history, issues, CI and the habits of everyone who already has the repository cloned all move on different tracks, and some of them do not move at all yet. This page says which is which, so you can decide before you start rather than discover it halfway.
Pick a route in
Section titled “Pick a route in”| You have | Use | Guide |
|---|---|---|
| A repository on GitHub | The GitHub import — we clone it, your GitHub copy is untouched | Migrating from GitHub |
| A local checkout, wherever it came from | neo adopt — push it here and make neosource its origin |
Migrating from GitHub → Bring a local checkout |
| A whole directory of projects | neo migrate ~/code — one repository per checkout found |
Migrating from GitHub → Move everything at once |
| A public repository somewhere else | Import from a public Git URL — no account linking | Migrating from GitHub → From a public Git URL |
What comes across
Section titled “What comes across”All of your history. Every branch and every tag, as the real objects — not a squashed snapshot and not a shallow clone. neosource’s storage engine is content-addressed, so an import is a transfer of objects rather than a replay of commits, and the commit IDs you had are the commit IDs you get.
Issues, comments and labels — if you ask for them. GitHub issue metadata is a separate opt-in from the code, available on repositories that came in through the authenticated GitHub import. See syncing issues.
Your identity, if you want to claim it. A GitHub handle can be claimed on neosource by proving you control it, so the name people know you by does not have to change. See Authentication.
What does not
Section titled “What does not”Your CI. neosource reads .neosource/workflows/, and nothing in
.github/workflows/ is ever registered or dispatched. The files are parsed and
reported on — the repository’s Actions tab lists each workflow with whether it
would run as-is and any warnings against it — but an imported repository has no
CI until you move and adapt them. Start at
Coming from GitHub Actions.
Pull requests. Open PRs on GitHub do not become open PRs here. Branches come across, so the work is not lost — the review threads are.
Stars, watchers, forks and releases. Social and release metadata stays where it is.
Not built yet
Section titled “Not built yet”These are known gaps, listed so you are not left guessing whether you missed a button:
- Issue import from Linear, Jira or GitLab. Only GitHub issue metadata has an importer today.
- Repository import from GitLab, Bitbucket or Gitea. Their public repositories work through the public Git URL route, which moves the code but no metadata; there is no authenticated, private-repo integration for them.
- Migrating a pull request with its review history.
- A CI status badge URL. There is no
badge.svgendpoint to point a README at yet, so a badge in a migrated README either keeps reporting GitHub Actions or comes out.
A word on not burning the bridge
Section titled “A word on not burning the bridge”Nothing about migrating requires you to delete anything. An import reads from
GitHub and never writes to it, and neo adopt demotes your old remote instead of
dropping it — the URL is still there under a second remote name. You can also
register a push mirror back to GitHub so the old home keeps receiving your
commits while people move over.
That is the recommended shape for a project with users: move the development here, keep the old location mirrored and pointing at the new one, and let the redirect do the work over time rather than in an afternoon.