Sadly, GitHub doesn't store its value-add assets within the repository itself; so all of the PR conversations, Gists, Issues, and so forth aren't within git itself.
It's the way the open source options work too (GitLab, Gitea, Forgejo), and they don't have any sinister motive for that—it's just easier to build that way.
This speaks to one of my secret desires, I've worked at a bunch of small companies now where the workflows were all ad-hoc and I feel like even at bigger companies there are persistent failures to "understand Git"... one of the most pernicious being that, most companies have a modernist "this is prod, it is one place running one codebase" approach, Git is postmodernist "here is this project, there are many branches showing different perspectives on what this code could be", most CI/CD systems in my opinion sit at the interface between these and choose the wrong side to be on, they choose the Git side -- "we ask every branch, 'do you want to deploy yourself to prod?' and if it says yes by virtue of having a CI.yaml file with a branch filter naming itself to be run, then we deploy it to prod."
So what I want is kind of to build a company that's just strongly opinionated about that... "everything is in one Git repository, the `main` branch is authoritative for ACLs and CI/CD config, the bugtracker writes issues directly into that repository and has an ACL role that allows it to do that, the RFC widget writes your code design docs directly in there as well, we do rebase but we merge without fast-forwarding, you have to use semver and it works like this..." and probably nobody will use our offering because "GitHub is more trustworthy" but "if anybody does they'll love us" haha
