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.
... continue reading