Finish the empirical check of the migration guide's transfer claims #184

Nytt ärende

supernaut · 2026-08-02T23:32:06Z

supernaut kommenterad

2026-08-02 23:32:06 +00:00

Ägare

The migration guide (gitborg/gitborg-web#182) states what does and does not come across when a
repository is imported from GitHub or GitLab. Its definition of done required every claim to be
checked against a real import. That check was run and only partly completed, so the guide ships
with some rows verified empirically and the rest grounded in the migration form source at the pinned
Forgejo version.

This issue closes that gap.

What is already confirmed

Verified by importing sindresorhus/slash into a scratch repository on the instance, since deleted:

the GitHub import path works for a public repository with no access token
the repository description transfers
releases transfer exactly — 5 at the source (v3.0.0, v4.0.0, v5.0.0, v5.0.1,
v5.1.0), 5 imported, with the blank release titles preserved
an unauthenticated import does not fail on GitHub's API rate limit, it crawls — the finding
that produced the guide's warning to use a token when importing issue history

What is still unverified

Each of these is a row in the guide's tables, currently sourced from the migration form template at
the pinned version rather than from an observed import:

branches, tags and full history
issues, with their comments
pull requests, with their comments, including closed and merged ones
labels
milestones
wiki
that branch protection, webhooks, stars and watchers do not come across

Why it stalled, and how to finish it

GitHub allows roughly 60 unauthenticated API requests per hour. Both attempts exhausted it on issue
and pull request pagination and never reached a serving state — the scratch repository returned a
500 on git ls-remote throughout, which is why the git-data rows are unverified.

An access token removes the constraint. With a fine-grained GitHub token with public read, the
same import finishes in minutes. Repeat it against a small public repository that actually has all
six item types — issues, pull requests, labels, milestones, releases and a wiki — rather than one
that merely has few of them, since an empty category verifies nothing.

Note that both attempts were interrupted by killing the client while the server-side task continued.
That may leave a repository stuck in the migrating state, and the 500 above should not be read
as a Forgejo defect without reproducing it on an uninterrupted run.

Definition of done

every unchecked row above is confirmed against a real import, or the guide is corrected where the
observed behaviour differs
the scratch repository is deleted afterwards
the guide cites what was verified, so the next person does not repeat the work

Part of gitborg/gitborg-docs#28.

The migration guide (gitborg/gitborg-web#182) states what does and does not come across when a repository is imported from GitHub or GitLab. Its definition of done required every claim to be checked against a real import. That check was run and **only partly completed**, so the guide ships with some rows verified empirically and the rest grounded in the migration form source at the pinned Forgejo version. This issue closes that gap. ## What is already confirmed Verified by importing `sindresorhus/slash` into a scratch repository on the instance, since deleted: - the GitHub import path works for a public repository with no access token - the repository description transfers - **releases transfer exactly** — 5 at the source (`v3.0.0`, `v4.0.0`, `v5.0.0`, `v5.0.1`, `v5.1.0`), 5 imported, with the blank release titles preserved - an unauthenticated import does not fail on GitHub's API rate limit, it **crawls** — the finding that produced the guide's warning to use a token when importing issue history ## What is still unverified Each of these is a row in the guide's tables, currently sourced from the migration form template at the pinned version rather than from an observed import: - [ ] branches, tags and full history - [ ] issues, with their comments - [ ] pull requests, with their comments, including closed and merged ones - [ ] labels - [ ] milestones - [ ] wiki - [ ] that branch protection, webhooks, stars and watchers do **not** come across ## Why it stalled, and how to finish it GitHub allows roughly 60 unauthenticated API requests per hour. Both attempts exhausted it on issue and pull request pagination and never reached a serving state — the scratch repository returned a 500 on `git ls-remote` throughout, which is why the git-data rows are unverified. **An access token removes the constraint.** With a fine-grained GitHub token with public read, the same import finishes in minutes. Repeat it against a small public repository that actually has all six item types — issues, pull requests, labels, milestones, releases and a wiki — rather than one that merely has few of them, since an empty category verifies nothing. Note that both attempts were interrupted by killing the client while the server-side task continued. That may leave a repository stuck in the migrating state, and the 500 above should **not** be read as a Forgejo defect without reproducing it on an uninterrupted run. ## Definition of done - every unchecked row above is confirmed against a real import, or the guide is corrected where the observed behaviour differs - the scratch repository is deleted afterwards - the guide cites what was verified, so the next person does not repeat the work Part of gitborg/gitborg-docs#28.

supernaut lade till etiketterna

area/web

ready-for-implementation

type

task

2026-08-02 23:32:13 +00:00

supernaut lade till detta till projektet Bitborg Web

2026-08-02 23:32:13 +00:00

supernaut refererade till detta ärende

2026-08-02 23:32:59 +00:00

docs(guides): add a migration guide for GitHub and GitLab #185

supernaut refererade till detta ärende från en incheckning