Hacker News Reader

Comment by mullr | Hacker News Reader

"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.

View on HN

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

There's also integration with GitHub pull requests for that:

https://github.com/google/git-pull-request-mirror

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

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.

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?

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!

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

Reply on news.ycombinator.com