> because Github “forks” don’t have their own issues/PRs
You can enable issues on forked repo, and any forked repo may receive PRs.
Still, manual repository is preferable as deleting repo will delete also its forks created using Github interface (at least it was happening some time ago)
My understanding was that when a repo is deleted one of its forks will be chosen to become the root instead; however if the parent repo is taken down (via DMCA etc.) then all its forks are also removed.
Yes. I had a similar thing happen a few months ago when I made a repo private - the first public fork became the upstream for all the other public forks.
>You can enable issues on forked repo, and any forked repo may receive PRs.
Their point was that issues in the new repo are completely separate from issues in the old repo. A new issue created in the new repo will be issue 1, and to browse the old repo's issues you have to navigate to the old repo. If the old repo is deleted all those issues will also be deleted and history will be lost.
That's why they mentioned the workaround of using the Github API to export the old repo's issues and re-import them into the new one, which would not be needed if issues were git objects and thus trivially copied into all forks.
You can enable issues on forked repo, and any forked repo may receive PRs.
Still, manual repository is preferable as deleting repo will delete also its forks created using Github interface (at least it was happening some time ago)