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.

do you have a link to a discussion?

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.

> It would be nice to have a provider-agnostic representation of this data.

Isn't the (original) e-mail workflow exactly that? Git was designed for it.

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.

> All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic.

I agree. Version control is a great enabler, so using it to track "sources" other than just code can be useful. A couple of tools I like to use:

- Artemis, for tracking issues http://www.chriswarbo.net/blog/2017-06-14-artemis.html

- ASV, for tracking benchmark results https://github.com/airspeed-velocity/asv (I use this for non-Python projects via my asv-nix plugin http://www.chriswarbo.net/projects/nixos/asv_benchmarking.ht... )