> 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. 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.
It’s really very simple, and it works well.