Code Review Can Be Better

Summary

Slightly unusual genre today: a negative result about our git-review tool for a different take on code review process, which we decided to shelve, at least for the time being. A lot of people are unsatisfied with GitHub’s code review process. One of the primary issues is that GitHub poorly supports stacked pull requests and interdiff reviews. While I also see interdiff as valuable, it’s not the reason why I decided to experiment with git-review. I have two other problems with GitHub, and with every single other code review system, with the exception of the thing that Jane Street uses internally: review state is not stored as a part of repository itself, review is done via remote-first web-interface. Let’s start with the second one. By the way of analogy, I don’t use GitHub’s web editor to write code. I clone a repository locally, and work in my editor, which is: fully local, memory/nvme latencies, no HTTP round-trips, tailored to my specific odd workflow. When I review code, I like to pull the source branch locally. Then I soft-reset the code to mere base, so that the code looks as if it was written by me. Then I fire up magit, which allows me to effectively navigate both through the diff, and through the actual code. And I even use git staging area to mark files I’ve already reviewed: Reviewing code rather than diff is so powerful: I can run the tests, I can go to definition to get the context, I can try out my refactoring suggestions in-place, with code completion and the other affordances of my highly sophisticated code editor. Alas, when I want to actually leave feedback on the PR, I have to open the browser, navigate to the relevant line in the diff, and (after waiting for several HTTP round-trips) type my suggestion into a text area. For some reason, the text area also regularly lags for me, especially on larger diffs. Two things are wrong here. On the interface side, review feedback is text related to the code. The most natural interface is to just leave revi...