3 ms·
> 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 i
by matkoniecz 6y ago
> 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)
- srtjstjsj 6y agoWait, what? Upstream can destroy my repo by deleting theirs? That's horrific if true.
- mook 6y agoMy 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.
- j-james 6y ago> as deleting repo will delete also its forks I haven't observed this to happen - in my experience, the first fork becomes the new "upstream" for all the rest.
- Arnavion 6y agoYes. 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.
- Arnavion 6y ago>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.