Reviewing so called Pull Requests at $dayjob

# Reviewing so called Pull Requests at $dayjob Source: [https://rkta.de/dayjob-pr-review.html](https://rkta.de/dayjob-pr-review.html) ## Rene Kita's weblog [Blog](https://rkta.de/index.html)[About](https://rkta.de/about.html)[RSS](https://rkta.de/feed.xml)[Links](https://rkta.de/links.html)[Code](https://git.rkta.de/)2026\-01\-14In 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](https://rkta.de/dayjob-pr-review.html#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\. As a[good citizen](https://sethrobertson.github.io/GitBestPractices/#sausage)I will not create new commits to fix those things, but will amend those fixes to that commit where it should have been done in the first place\. With an traditional email\-based workflow I would wait for some time to collect all feedback, fixup all my commits and then send a v2\. With those web\-based workflows I would need to create another PR or I can replace the previous version by doing a force push\. After a force push the previous version is gone and as a reviewer I would have to review the complete patch set again\. When being assigned as a reviewer to a PR I usually workaround those deficiencies the following way, assuming my coworker wants to merge branch origin/feature and force pushes after amending the commits[\#1](https://rkta.de/dayjob-pr-review.html#1): 1. Creat branch from remote:`git checkout \-b v1 origin/feature` 2. Review commits:`git log \-p \-\-reverse origin/master\.\.` 3. Give feedback, wait for them to fix it 4. Fetch and creat branch from remote:`git fetch; git checkout \-b v2 origin/feature` Now I have a v1 and v2 as I would have with the traditional workflow and can use git\-range\-diff\(1\) to compare both revisions:`git range\-diff origin/master\.\.v1 origin/master\.\.`If the commits are a horrible mess \(at $dayjob we allow squashing at merge\) I use`git diff origin/master`instead of the`git log \-p \-\-reverse`step\. For the patch review step \(with`git log \-p \-\-reverse`\) I will usually skim all the commits\. If I want to add more than just one or two comments, I usually pipe the log into my editor so that I can add comments while reading the changes:``` git log -p --reverse origin/master.. | sed 's/^/> /' | vim -c 'set filetype=mail' - ``` When done doing the review I just need to copy my comments into the web interface \- which is still annoying, but less so\. \-\-0: There is nothing pulled in this process\.\.\.1: Works the same if they create a new PR, just base v2 on the branch of the new PRLast modified: 2026\-01\-14T23:15:04Z ---