This makes me realize that Github’s domain model (where “issues” exist as objects associated with—but outside of—the repo) is kind of hostile to forking. The original author wants to close issues not because they’ve been fixed in the codebase, but because he wants to not solve them. To get those same issues “back”, a fork developer would have to:
1. Copy-and-paste the repo, rather than using Github’s forking mechanism, because Github “forks” don’t have their own issues/PRs (being something more equivalent to multi-branch workdir collections for an upstream repo);
2. Copy all the issues over from the origin repo (manually, or by writing a script against Github’s API/CLI);
3. Sadly, likely lose all the original conversation on those issues.
These problems would be obviated if issues were just data files committed inside the repo — with any branch that contains the open issue file meaning the issue pertains within that branch; and any branch that closes the issue meaning that the issue is solved as of that commit. A fork developer could just fork the repo in the traditional fashion, and end up with a fork of all the issues alongside.
Does any git hosting service/software handle issues in this fashion, i.e. as a layer of web-chrome and backend indexing over files committed to branches of the repo (where you’d always have to be looking at the issues as they exist within a particular branch)?
For that matter, does any git hosting service have a sane high-level set of workflows for “forking” in the sense of creating a competing (or replacement) maintained-upstream-repo for people to contribute to?
> 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.
> To get those same issues “back”, a fork developer would have to:
1. Agree with the original author that a fork/take-over is the right thing to do.
2. Create a GitHub organisation for the project, where rights and repos and everything can be re-allocated/delegated as needed.
3. Make original author transfer his repo to this organisation.
4. Done. No more steps.
It also includes magic redirects for all requests to the old repo, including issues and also git-request, so down-stream projects won’t even have to know.
Not so simple if the original developer is dead, MIA, or uncooperative.
I think this is a clear deficiency of git and many other VCSs, which fossil avoids. It's clear that bug reports and commits will frequently cross-reference each other, so they should be tracked in the same system. Git only implements one half of the puzzle, leaving the other half up to others which ultimately facilitates vendor lockin.
1. Copy-and-paste the repo, rather than using Github’s forking mechanism, because Github “forks” don’t have their own issues/PRs (being something more equivalent to multi-branch workdir collections for an upstream repo);
2. Copy all the issues over from the origin repo (manually, or by writing a script against Github’s API/CLI);
3. Sadly, likely lose all the original conversation on those issues.
These problems would be obviated if issues were just data files committed inside the repo — with any branch that contains the open issue file meaning the issue pertains within that branch; and any branch that closes the issue meaning that the issue is solved as of that commit. A fork developer could just fork the repo in the traditional fashion, and end up with a fork of all the issues alongside.
Does any git hosting service/software handle issues in this fashion, i.e. as a layer of web-chrome and backend indexing over files committed to branches of the repo (where you’d always have to be looking at the issues as they exist within a particular branch)?
For that matter, does any git hosting service have a sane high-level set of workflows for “forking” in the sense of creating a competing (or replacement) maintained-upstream-repo for people to contribute to?