PR review tooling idea

Stream: general

[Johan Commelin]

I want to review github PRs interactively in my editor (VS Code, neovim, emacs, et), using lsp features etc. I also want to post review comments on github with code suggestions, because that makes it really easy for the PR author to apply my suggestions. But this involves a lot of context switching for me. After checking out the PR locally, and loading it in my editor, I can play around with the code, and try out improvements. Once I'm happy, I have to copy paste the changes, switch back to the editor, find the corresponding part of the diff in the web UI (in a large PR that changes several files etc), select the correct range of lines, paste the suggestion in a

```suggestion

block, and submit the review comment. Then switch back to the editor to review the next hunk in the PR.

What I would love is that I checkout a new branch <PR-number>_review and make atomic commits there, right from the editor. With the intended comment in the commit message. Then some script turns each of those commits into a github review comment on the right range of lines, and uses the commit message to write the comment, and the patch of the commit to create a

```suggestion

block.

Does anyone know of such a tool? Or interested in creating it?

[Yiming Fu]

Maybe GitHub Pull Requests

[Floris van Doorn]

Fair warning that the Github Pull Requests extension does not play well with the Lean extension, because of a bug that Github Pull Requests (seemingly) has and doesn't want to fix

[Johan Commelin]

Last time I looked at that VSCode extension, it couldn't do what I'm asking for. It still required manually taking your code changes in the editor and turning them into a review comment.
On top of that, the problem that Floris points out makes it quite a no-go :sad:

[Bryan Gin-ge Chen]

I only tried it once or twice and I'm not sure if the setup for mathlib still works anymore but I think there was an interface for making suggestions onto a PR from GitHub codespaces.

[Robin Carlier]

I sometimes use octo.nvim, though it’s not perfect. It at least lets me post github suggestions from the editor, but infoview is unavailable when it is in diff/review mode (edit: I retested, and it works! but there is no infoview available for the "old" diff, so you can’t compare infoview behaviour side by side between before and after the PR easily).

I usually deal with that by having the files modified in the PR open in buffers in a separate editor tab (for them, infoview is available as usual) which lets me go back-and-forth easily between review mode and regular edit mode by going through tabs. But I 100% agree the best (which would also probably end up being an editor-independent script) would be something that turns commits on a local branch into a batch of suggestions.

[Bryan Gin-ge Chen]

So I did find https://github.com/getsentry/action-git-diff-suggestions just now. It's archived and there is a warning that it doesn't work because GitHub doesn't allow making suggestions on lines that were not modified in the PR.

I wonder if we should normalize having reviewers open "suggestion" PRs targeting the PR branches (rather than master)?

[Julian Berman]

Robin Carlier said:

I sometimes use octo.nvim, though it’s not perfect. It at least lets me post github suggestions from the editor, but infoview is unavailable when it is in diff/review mode (edit: I retested, and it works! but there is no infoview available for the "old" diff, so you can’t compare infoview behaviour side by side between before and after the PR easily).

I can't follow the thread carefully today until much later, but please file issues for this sort of thing if you like! Specifically, fixing this for fugitive which I use was pretty trivial.

[Filippo A. E. Nuccio]

I always review PR's inside VSCode and have 0 problems, and never use the github interface. It is true that I try things, then copy the code, click on the left to open the "suggest code" and past it there, but I configured a ctrl+alt+Z shortcut that restores the file, so when I'm happy I do this, revert the file to its original state and suggest the modification. I'm on Ubuntu now, but I had the exact workflow when on Win. Or am I misundestanding what you're asking for, @Johan Commelin? And yes, I'm relying on the GitHub PullRequest extension, although I've never experience the problem mentioned by Floris.

[Johan Commelin]

Aah, that Ctrl-Alt-Z trick is smart!

[Filippo A. E. Nuccio]

If you say so... I'd be happy to show you my PR review workflow next time we're at the same table, but I am honestly quite happy with the VScode interface.

[Riccardo Brasca]

You revert the file to the original state before making any comment? I remember having tried it but sometimes it was confused by line number because of modification I made to test my comment.

[Filippo A. E. Nuccio]

Well, before making the comment I copy my version, and I typically stay on the safe side, like copying the whole proof or the whole statement. Then I revert everything, select the whole proof/statement and click "suggest code": on the opened panel I paste my suggestion and click "suggest". So I'm not modifying the code but if the author is happy they can just accept my suggestion.

[Filippo A. E. Nuccio]

Johan Commelin said:

Aah, that Ctrl-Alt-Z trick is smart!

BTW, now that I've double-checked my muscle memory, it is Ctrl-Shift-Z, but I don't think that the smartest part was the choice of Alt....