Storing code review (and ci results, and analyzer runs) in git is a wonderful idea. All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic. It also enables the 'single pane of glass' to observe the a pull request from.
I assume it would also have the advantage of not tying the code reviews and PRs to a proprietary git provider.
Say I move from GitHub to GitLab, I assume I lose all the PR descriptions and comments people have made over the years and only keep the commit messages.
It would be nice to have a provider-agnostic representation of this data.
I seem to recall the gitea project working on something like git-tracked metadata (PRs, issues, etc), at least the idea has been floating around for a while. One problem with this idea that I haven't seen a good solution for is serializing issue numbers across distributed forks. Maybe we would give up nice sequential numbers and settle for hashed issue refs.
We could also hash the issue with a time sensitive UUID. Then they could be ordered but unique to each person assuming they don't create an issue in the same microsecond.
Same with things like issues and discussions, the only trouble is that it creates a lot of commits and possible churn. Which can be alleviated by storing the comments in a separate branch (so it doesn't affect the mainline), but even then the repo will get very big very fast.
But that may be a future problem, after all, removing a branch from a git repository (and its history) is fairly straightforward.
