5 ms·

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 kee

by bhawks 3y ago

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.

Arbortheus 3y ago
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.
- infogulch 3y ago
  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.
  - glodalitazic 3y ago
    do you have a link to a discussion?
  - yurishimo 3y ago
    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.
- palata 3y ago
  > 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.
Cthulhu_ 3y ago
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.
chriswarbo 3y ago
> 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 http://www.chriswarbo.net/blog/2017-06-14-artemis.html - ASV, for tracking benchmark results https://github.com/airspeed-velocity/asv 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.html http://www.chriswarbo.net/projects/nixos/asv_benchmarking.ht... )

by bhawks 3y ago

Arbortheus 3y ago

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.

infogulch 3y ago
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.
- glodalitazic 3y ago
  do you have a link to a discussion?
- yurishimo 3y ago
  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.
palata 3y ago
> 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.

Cthulhu_ 3y ago

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.

chriswarbo 3y ago

> 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 http://www.chriswarbo.net/blog/2017-06-14-artemis.html - ASV, for tracking benchmark results https://github.com/airspeed-velocity/asv 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.html http://www.chriswarbo.net/projects/nixos/asv_benchmarking.ht... )