Workflows for reviewing code

[casr]

I thought it would be nice to start a discussion around the various ways we use Fugitive to review code. I would love to be inspired with the various workflows that you might use day-to-day.

Ask yourself:

• What are your go-to commands within Fugitive? Maybe you also pair that with other tools?
• What parts of your workflow have you not quite cracked yet? Maybe those companion tools mentioned above are actually fallbacks for something you think is missing? Perhaps others will be able to help you plug those gaps.
• Do you like to review commit-by-commit or as one big diff? What helps you to do either one?
• What shortcuts have you created to aid in your workflow?

---

I'll kick off.

I tend to favour one giant diff reviews as that is usually how they're presented to me (for better or worse). I like to check out the branch for reviewing. This way I can play around with review suggestions before I raise them.

git fetch origin main topic-branch  # get latest changes from both the trunk and branch
git checkout topic-branch

One handy command in Fugitive is the :h :Git_difftool which I like to use with the -y switch. This ends up looking like:

G difftool -y origin/main...

which opens a new tab per file that has changed since this was branched from main. Each tab additionally contains a diff split showing the changes. I then scan through the tabs with gt to go to the next tab or gT to go back to the previous tab. Unfortunately, this approach has the limitation of purely in fugitive: style urls so doesn't benefit from an editable buffer or things like an LSP server providing diagnostics. I've worked around this with a command like:

tabdo Gedit | windo diffthis

which, given that each tab defaults to selecting the more recently changed file, snaps that split back to the file that's on disk and then reapplies diff mode.

That about wraps up my best tricks. Love to hear what you've got!

[tpope]

I'll admit, I tend to default to the GitHub web view, as that fetch/checkout is just tedious enough that I don't usually bother unless I actually want to run the code.

Unfortunately, this approach has the limitation of purely in fugitive: style urls so doesn't benefit from an editable buffer or things like an LSP server providing diagnostics.

This happens because origin/main... is short for origin/main...HEAD: You're explicitly telling it to use the committed content. If you pass origin/main as the argument instead, it will diff against the work-tree version, which is the same state you end up in after the tabdo.

[casr]

Oh, it's such a simple fix. Thanks for highlight the difference in those ref specs.

[casr]

I've rediscovered why I got into this habit of origin/main... and that's because the trunk branch can move on and then you'll get unrelated changes when you want to only analyse what would be introduced in this branch.

I tried to look through man git-revlist to see if there was a way to reference the current work tree with the three dot notation but haven't found anything.

[tpope]

git merge-base origin/main HEAD will get you the common ancestor, then you can pass that as an argument to :Git difftool. Unfortunately it's a 2 step solution, so if you want to do it regularly, you'll probably want to create a function/command/map to automate it.