That sounds absolutely terrible, mailing list style code reviews (and, frankly, everything else associated with mailing lists) is the worst, least productive, most convoluted form of communication I’ve ever experienced.
It is super useful, but it still requires some love around ergonomics. I would love for example prr edit that would automatically open review in $EDITOR. Some way to autodetect the repository to be able to do prr get 2137 instead of prr my-org/my-repo/2137. Maybe some integration with gh would be nice as well.
Overall thanks @dxu for the tool as it is really handy.
I was thinking lately how backward our reviewing code tools are. We fine tune our tools to be super efficient at reading and browsing code. Meanwhile the time where I spend the most time reading code is in the worst web UIs without any of my usual tool and bindings. Looking forward to try this tool!
I tried it on a PR with many comments (https://github.com/llvm/llvm-project/pull/72714) but got an error from GitHub (sorry, not saved locally). Unfortunately the error message isn’t clear which chunk is corrupted. I ended up copying the comments to the web UI…
I might have to try it out just to be able to search the whole diff. GitHub “helpfully” collapsing the file with all of the changes makes it easy to miss the most important parts of a change.
However reading the README it seems that whitespace separates comments? Or am I just not understanding their wording? I very frequently leave multi-paragraph comments.
Another thing I would miss is screenshots and videos for UI review. It would be cool if you could put a markdown link to a local file and it would be uploaded.
Multi-paragraph comments are ok. Whitespace in the quoted (diff) part of the file delineates scoped comments. You could ignore this feature altogether and still get by IMO.
For those who wondered
https://github.com/danobi/prr
That sounds absolutely terrible, mailing list style code reviews (and, frankly, everything else associated with mailing lists) is the worst, least productive, most convoluted form of communication I’ve ever experienced.
“Mailing-list” style as in editing the review locally, instead of the GitHub web UI.
The recieving side is not forced to use e-mail or anything other than GitHub.
It is super useful, but it still requires some love around ergonomics. I would love for example
prr editthat would automatically open review in$EDITOR. Some way to autodetect the repository to be able to doprr get 2137instead ofprr my-org/my-repo/2137. Maybe some integration withghwould be nice as well.Overall thanks @dxu for the tool as it is really handy.
I submitted a PR for
prr edit.This is awesome. I cannot figure out what permissions to add in a fine-grained PAT. Do you have some docs for this?
Super interesting, thanks for sharing this! Will definitely be giving this a whirl
I made a basic prr mode for Emacs too: https://github.com/elliotekj/prr-mode.el
I was thinking lately how backward our reviewing code tools are. We fine tune our tools to be super efficient at reading and browsing code. Meanwhile the time where I spend the most time reading code is in the worst web UIs without any of my usual tool and bindings. Looking forward to try this tool!
prr is really cool!
I tried it on a PR with many comments (https://github.com/llvm/llvm-project/pull/72714) but got an error from GitHub (sorry, not saved locally). Unfortunately the error message isn’t clear which chunk is corrupted. I ended up copying the comments to the web UI…
Ouch, sorry. If you manage to figure out how to reproduce it please lmk.
I had a similar experience a while ago (frustrating, I know) which led to https://github.com/danobi/prr/commit/ba0a41ac5580ba18db2052ac971ed378949f9378. Sounds like it didn’t catch your error though.
I might have to try it out just to be able to search the whole diff. GitHub “helpfully” collapsing the file with all of the changes makes it easy to miss the most important parts of a change.
However reading the README it seems that whitespace separates comments? Or am I just not understanding their wording? I very frequently leave multi-paragraph comments.
Another thing I would miss is screenshots and videos for UI review. It would be cool if you could put a markdown link to a local file and it would be uploaded.
Multi-paragraph comments are ok. Whitespace in the quoted (diff) part of the file delineates scoped comments. You could ignore this feature altogether and still get by IMO.