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.
Any solution has its cons. Github workflows has downsides and this solution does solve them (and introduces its own). But what I am not getting is why this approach is better than the email workflow.
The downsides of email workflow that the author mentioned are (1) Having to setup mailing list, (2) setting the mail client, (3) friction in submitting a patch, which I assume the author is referring to setting git-send, (4) email is limited such as not being able to modify it, not being able to download the patch, and limitation around the plain-text, and the author doesn't hint into what limitation he is thinking of.
These are downsides of email workflow, and I do not think they are significant (except for 1, which could be done though a person's email address if the project is small). But the SSH workflow replaces them with similar issues such as (1) setting SSH server and maintaining it and the cost associated with it, (2) clients will need to maintain their identities though SSH, (4) replace email-replies with code comments (email-replies is better as you can do more than just text). (3) Here SSH workflow is better as it requires no work, but configuring git-send is a very small and usually 1-time change.
In most cases, the only mail client requirement is to be able to write plain text. Virtually all mail clients can do this with a simple checkbox. Only the maintainer will need ability to `git am' the patch from an email message, and this is indeed a downside of email workflow.
All in all, nothing wrong with more options, and I am sure SSH meets certain needs, but to me email-workflow and SSH compete in the same category and email-workflow is superior.
Eh, (2)/(3) can be a pain for web mail accounts. For instance, I couldn't send patches to LKML through Gmail directly, since even for plain-text emails it wants to rewrap long lines itself. To get "git send-email" working through it, I had to wade through a bunch of outdated info to find the right method.
Even now there are persistent downsides: every email through "git send-email" contains my original IP address for everyone to see, unless I use a VPN service. Also, since I'm not a right-thinking person with a 'real' client-based inbox, I have to fiddle with the In-Reply-To and References headers by hand, if I want to include a patch in a reply to another email.
> every email through "git send-email" contains my original IP address for everyone to see
Is this the fault of git or your SMTP provider? I looked through a mailman archive and couldn't find my client IP address. The first Received headers refer to my email host.
Can you expand a bit more why this workflow (send patch over ssh, and rss feeds for owner), is better than either email workflow or using a centralised service with Pull Requests.
This seems to come very close to recognising that if someone without permissions pushes something to a repository, it should be convered into a PR.
> If you've ever used the email workflow I don't think I need to explain why it sucks.
I prefer it FWIW. After setting up your Email, it is much easier and faster to send a mail than go through a PR-process. On the reciving end you can respond inline to the patch, in the compfort of your email client, without having to use a browser.
My feeling is that people who don't like this, don't have a good mail setup (which is understandable given some hosts), making Email much more painful to use in general.
On the general idea, I'm thoroughly in support of alternative interfaces and workflows, so I see git-pr as a net win.
On the above steps, I feel it's misrepresenting what github/gitlab have to offer. The only real step would be "have an account on the platform" and looking at the file in a browser. From there creating a MR/PR in a new branch with the changes you want is painless and a matter of 3 or 4 clicks.
It works very well for repos with config files that only need the CI to be green, you get a full MR in 1 min if you want to.
Thank you for that feedback, I removed a couple important pieces from the repo readme that I think would answer your questions around usage. I'll add them into the main site.
I think gerrit seems to use this same kind of workflow, but with a git frontend (but just for transmitting the patches). More convenient than arcanist IMO.
Yeah me too. I used Phabricator extensively and in practice it is basically the same as Gitlab and GitHub and everyone else. You just say `arc diff` instead of `git push`.
Phabricator was pretty nice overall I would say. The bug tracker in particular was good. I have to use Jira now and it's night and day.
The big flaw was there was essentially no CI support. That and the fact it was written in PHP, which you'd think wouldn't matter, but I did end up being forced to learn some PHP to fix Phabricator bugs and write custom linters.
Now we're using Gitlab which is also decent except it's written in Ruby which if anything is worse than PHP! Absolutely unreadable code base. I can't fix anything. (Except in gitlab-runner which is written in Go - I've contributed several fixes & features there.)
I like the basic philosophy that everything should be inside the code (yes lots of great collaboration and review tools out there with great browser based diffing- it’s just I am thirty years of reading code and writing code in a tool and I kinda get used to the code in the tool
I agree for smaller projects, especially personal ones. For larger projects, approaches like GitHub's web client + terminal interface might be the next best thing since grepping doesn't scale well. For better or worse, GitHub branding also helps make their specific terminal tool an easier sell in large org environments.
GitHub's web client does not scale at all in my opinion. It is very slow to load source large patches, and the code navigation experience is not great, hence why they brought VSCode for Web to the product, but still.
Heh, well GitHub's search doesn't exactly scale well either. They _still_ only index the main branch, so if you want to find anything under active development or on an old tag version you're out of luck, clone + grep is the only way.
I don't really understand this argument. It is not like a web based tool is stopping you from seeing the code in your editor. You just check out the code and now you are seeing the code in your fav editor. Which is exactly the same process you would use with this tool.
> Definitely not my experience with VSCode and GitHub's PR extension
What about other editors and IDEs? It might work great for VSCode, heavily leveraging vertical integration, but everything else is out of scope.
`git-pr` removes all of this overhead by being creative with its design. You don't need a VSCode extension, just write the review in code and we help make that manageable.
Absolutely, I was just responding to the herculean effort part. I realize it's a nit, but I think it might be more accurate to say that not all editors are supported, because in some cases it takes barely any effort at all.
GitHub has done a good job of getting the product into VSCode. I think this product is targeting people who already likely using a terminal editor and work well within a CLI environment, which is what all of Pico's services are trying to do already.
Readit News
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.
I think it mesh well with worktree, you can setup one dedicated to review.
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.
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).
The downsides of email workflow that the author mentioned are (1) Having to setup mailing list, (2) setting the mail client, (3) friction in submitting a patch, which I assume the author is referring to setting git-send, (4) email is limited such as not being able to modify it, not being able to download the patch, and limitation around the plain-text, and the author doesn't hint into what limitation he is thinking of.
These are downsides of email workflow, and I do not think they are significant (except for 1, which could be done though a person's email address if the project is small). But the SSH workflow replaces them with similar issues such as (1) setting SSH server and maintaining it and the cost associated with it, (2) clients will need to maintain their identities though SSH, (4) replace email-replies with code comments (email-replies is better as you can do more than just text). (3) Here SSH workflow is better as it requires no work, but configuring git-send is a very small and usually 1-time change.
In most cases, the only mail client requirement is to be able to write plain text. Virtually all mail clients can do this with a simple checkbox. Only the maintainer will need ability to `git am' the patch from an email message, and this is indeed a downside of email workflow.
All in all, nothing wrong with more options, and I am sure SSH meets certain needs, but to me email-workflow and SSH compete in the same category and email-workflow is superior.
Even now there are persistent downsides: every email through "git send-email" contains my original IP address for everyone to see, unless I use a VPN service. Also, since I'm not a right-thinking person with a 'real' client-based inbox, I have to fiddle with the In-Reply-To and References headers by hand, if I want to include a patch in a reply to another email.
Is this the fault of git or your SMTP provider? I looked through a mailman archive and couldn't find my client IP address. The first Received headers refer to my email host.
- have an account on the platform
- fork the repo
- pull repo
- create a branch
- make the change
- push to forked repo
- click a button in the UI to create the PR
With `git-pr` it can be this simple:
- pull repo
- make the change
- submit pr with a single command `git format-patch | ssh host pr create x`
If you've ever used the email workflow I don't think I need to explain why it sucks.
> If you've ever used the email workflow I don't think I need to explain why it sucks.
I prefer it FWIW. After setting up your Email, it is much easier and faster to send a mail than go through a PR-process. On the reciving end you can respond inline to the patch, in the compfort of your email client, without having to use a browser.
My feeling is that people who don't like this, don't have a good mail setup (which is understandable given some hosts), making Email much more painful to use in general.
On the above steps, I feel it's misrepresenting what github/gitlab have to offer. The only real step would be "have an account on the platform" and looking at the file in a browser. From there creating a MR/PR in a new branch with the changes you want is painless and a matter of 3 or 4 clicks.
It works very well for repos with config files that only need the CI to be green, you get a full MR in 1 min if you want to.
Notice that `git-pr` still has a centralized service, just an SSH-based one rather than HTTP-based. I don't see a win there.
> 4. External contributor submits a PR to SSH server But how? That numbered list let me think of that old cartman profit meme.
I like the idea, but I'm not convinced yet, that this is really easier than just sending an email by `git request-pull`.
Phabricator was pretty nice overall I would say. The bug tracker in particular was good. I have to use Jira now and it's night and day.
The big flaw was there was essentially no CI support. That and the fact it was written in PHP, which you'd think wouldn't matter, but I did end up being forced to learn some PHP to fix Phabricator bugs and write custom linters.
Now we're using Gitlab which is also decent except it's written in Ruby which if anything is worse than PHP! Absolutely unreadable code base. I can't fix anything. (Except in gitlab-runner which is written in Go - I've contributed several fixes & features there.)
Definitely not my experience with VSCode and GitHub's PR extension, but I don't think I'm the target audience for this product anyway.
What about other editors and IDEs? It might work great for VSCode, heavily leveraging vertical integration, but everything else is out of scope.
`git-pr` removes all of this overhead by being creative with its design. You don't need a VSCode extension, just write the review in code and we help make that manageable.