5 ms·

"Code reviews become annotations" - cool feature, and it identifies a real problem. I don't think it solves it though. We've learned many times that your sourc

by mullr 11y ago

"Code reviews become annotations" - cool feature, and it identifies a real problem. I don't think it solves it though. We've learned many times that your source code and its history are the thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments. That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, that would be cool.

justinsb 11y ago
I agree with this, and recently learned about https://github.com/google/git-appraise https://github.com/google/git-appraise which I believe stores the code reviews in the repo itself.
- procrastitron 11y ago
  There's also integration with GitHub pull requests for that: https://github.com/google/git-pull-request-mirror https://github.com/google/git-pull-request-mirror
- infogulch 11y ago
  This looks like a viable alternative to centralized solutions. I didn't even know git-notes[0] existed until I read that git appraise uses it. [0]: https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
- timr 11y ago
  Hi there, author of Omniref here. There's a substantial difference between what we're doing, and what git-appraise is doing. Git appraise is solving the problem of decentralized code review, but it doesn't solve the problem of making code reviews discoverable, after you've done them: having a directory full of JSON files doesn't make it easy to go from a line of code to the review that created it. In other words: we're trying to make it possible to look at your code, and see every bit of historical information, in context, that made it as good (or bad) as it is at that moment. That said, having the ability to export our annotations to a directory full of JSON files is high on the to-do list. You should absolutely be able to work with your own data.
allanderek 11y ago
This is a good point. In particular what happens if you fork a repository, do you lose the meta-data? What happens if you have a fork for coordination of a sub-team, are the pull-request annotations created on that fork also available with the main repository once it is merged in?
- timr 11y ago
  Good point! Right now it isn't fork-aware, but there's no reason, in principle, that the annotation data couldn't (or shouldn't) be forked with the repo. I'll file that as a to-do!
woah 11y ago
How is this different from emails or IRC conversations about the code?

by mullr 11y ago

justinsb 11y ago

I agree with this, and recently learned about https://github.com/google/git-appraise https://github.com/google/git-appraise which I believe stores the code reviews in the repo itself.

procrastitron 11y ago
There's also integration with GitHub pull requests for that: https://github.com/google/git-pull-request-mirror https://github.com/google/git-pull-request-mirror
infogulch 11y ago
This looks like a viable alternative to centralized solutions. I didn't even know git-notes[0] existed until I read that git appraise uses it. [0]: https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
timr 11y ago
Hi there, author of Omniref here. There's a substantial difference between what we're doing, and what git-appraise is doing. Git appraise is solving the problem of decentralized code review, but it doesn't solve the problem of making code reviews discoverable, after you've done them: having a directory full of JSON files doesn't make it easy to go from a line of code to the review that created it. In other words: we're trying to make it possible to look at your code, and see every bit of historical information, in context, that made it as good (or bad) as it is at that moment. That said, having the ability to export our annotations to a directory full of JSON files is high on the to-do list. You should absolutely be able to work with your own data.

allanderek 11y ago

This is a good point. In particular what happens if you fork a repository, do you lose the meta-data? What happens if you have a fork for coordination of a sub-team, are the pull-request annotations created on that fork also available with the main repository once it is merged in?

timr 11y ago
Good point! Right now it isn't fork-aware, but there's no reason, in principle, that the annotation data couldn't (or shouldn't) be forked with the repo. I'll file that as a to-do!

woah 11y ago

How is this different from emails or IRC conversations about the code?