Reviewing so called Pull Requests at $dayjob
Rene Kita describes his experience reviewing pull requests using a Microsoft-hosted git platform at his day job. He outlines the challenges of the web UI and handling force‑push updates, which erase previous versions of the review. He proposes a workflow that creates local branches and uses git range‑diff to compare revisions before copying comments back into the web interface.
- ▪Kita has spent three years embedded in a customer’s team where they use a Microsoft product to host git repositories and manage pull requests.
- ▪The web‑based review UI is considered poor, and force‑pushed updates remove the prior version, forcing reviewers to re‑review the entire patch set.
- ▪Kita’s workaround involves checking out separate local branches (v1 and v2) from the remote feature branch and using git range‑diff to compare the two revisions.
- ▪For detailed review he runs git log -p --reverse, pipes the output into an editor to add comments, and then copies those comments into the web interface.
Opening excerpt (first ~120 words) tap to expand
Rene Kita's weblog Blog About RSS Links Code Reviewing so called Pull Requests at $dayjob 2026-01-14 In the last three years I spend quite some time being embedded in a customer's team for my $dayjob. They use a lovely Microsoft product to host the git repositories and do so-called "pull requests"(PR)#0 to bring changes into the master branch. As expected from a Microsoft product the UI to review a PR is absolutely horrible. Another problem, as with all web-based review interfaces, is reviewing iterations after the initial review. Let's say I create a PR and get first feedback, e.g. some smalls nits or oopsies I included in one of my commits.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Rkta.
Discussion
0 commentsMore from Rkta
