There's definitely something very interesting here.
Keeping the user in their editor for code reviews is pretty nice indeed, but I think that with larger projects and bigger changes, it's going to be way more difficult to skim through what has changed where, which helps me identify how to start reviewing. There would have to be an easier way to see what changed where quickly without having to mess up my working tree (which is almost always dirty with something) and having to stash or switch back and forth between branches for reviewing is going to be painful. Sometimes I have small comments or questions, I'd like to be able to do that without having to download the entire patch.
Also, I'm not sure if I missed something, but does every review get applied as a commit by itself that I (as repo owner) would have to squash? This feels like a chore by itself.
I have relied on github for previous work but for the last couple of years I've been primarily using Gerrit for my job, and although there are some drawbacks, I absolutely love its workflow. Github workflow is not free from drawbacks either, and if I'm asked now I absolutely prefer Gerrit's to Github's. Gerrit uses Git references in a unique way to facilitate code reviews and patches (which consist of one or more patchsets). I rarely use branches now except for extremely long-lived experiments, or for local temp purposes. A patch gets merged as a single commit no matter how many rounds of patchsets the submitter adds and reviews they get, and when needed I can quickly download the patch at any patchset to a different branch and then delete it.
> There would have to be an easier way to see what changed where quickly without having to mess up my working tree (which is almost always dirty with something) and having to stash or switch back and forth between branches for reviewing is going to be painful.
I think it mesh well with worktree, you can setup one dedicated to review.
> There would have to be an easier way to see what changed where quickly without having to mess up my working tree (which is almost always dirty with something) and having to stash or switch back and forth between branches for reviewing is going to be painful. Sometimes I have small comments or questions, I'd like to be able to do that without having to download the entire patch.
I love this feedback and totally agree with you. Pulling a PR down and applying to review is great until you need to reference what's in main and have to ping-pong between them. At the end of the day, `git-pr` supports pushing and pull patchsets and we do have ideas around how a reviewer could review a patch request without applying it locally for something lighter-weight. Something like editing a patchset directly (with comments) and uploading that.
I think I need to play around with Gerrit. When originally developing this idea, I looked at Gerrit but didn't actually play around with it.
Someone else mentioned this already but I do want to experiment with revisions and supporting `git range-diff` workflows which I think could provide better support for larger reviews.
Gerrit is the gold standard of code reviews and I'll die on that hill. I've heard many a good things about phabricator too, but it requires lot of special tooling while gerrit just uses plain old git semantics.
That said, I live git-pr so far. I have a forgejo instance and I like it for what it provides, but without federation, external contributors aren't able to contribute.
If git-pr can be made to work with forgejo, I'll just go for it (self hosted, of course).
Gerrit is really good at code reviews. It is a matter of getting used to at first, but later it is very easy to track even differences between patchsets. It also marks you what you did not reivew if a new patchset is pushed, without marking the files that did not change. It lets you pick the changes locally if you want as well. I think it is very good for reviews.
Keeping the user in their editor for code reviews is pretty nice indeed, but I think that with larger projects and bigger changes, it's going to be way more difficult to skim through what has changed where, which helps me identify how to start reviewing. There would have to be an easier way to see what changed where quickly without having to mess up my working tree (which is almost always dirty with something) and having to stash or switch back and forth between branches for reviewing is going to be painful. Sometimes I have small comments or questions, I'd like to be able to do that without having to download the entire patch.
Also, I'm not sure if I missed something, but does every review get applied as a commit by itself that I (as repo owner) would have to squash? This feels like a chore by itself.
I have relied on github for previous work but for the last couple of years I've been primarily using Gerrit for my job, and although there are some drawbacks, I absolutely love its workflow. Github workflow is not free from drawbacks either, and if I'm asked now I absolutely prefer Gerrit's to Github's. Gerrit uses Git references in a unique way to facilitate code reviews and patches (which consist of one or more patchsets). I rarely use branches now except for extremely long-lived experiments, or for local temp purposes. A patch gets merged as a single commit no matter how many rounds of patchsets the submitter adds and reviews they get, and when needed I can quickly download the patch at any patchset to a different branch and then delete it.