Git-PR: patch requests over SSH

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.

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.

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.

After reading the website and also trying the mentioned `ssh pr.pico.sh help` I still don't know what exactly to do to use this.

> 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`.

That you, looks interesting. But the license is not specified on Github.

Patch review flow was one of the thing I've really enjoyed with Phabricator.

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

> There are tools and plugins that allow users to review PRs inside their IDE, but it requires a herculean effort to make it usable.

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.

> Github is bringing the IDE to the browser in order to support their workflow, we want to flip that idea on its head by making code reviews a first-class citizen inside your local development environment.

What like this? https://marketplace.visualstudio.com/items?itemName=GitHub.v...

I'm all for standardising the pull request process but their suggested workflow sounds way worse than what we have now. Given how dominant Github is I seriously doubt anyone except the nerdiest nerds will use this.

IMO if anyone is going to solve this it's going to have to happen inside Git, which I can't see happening.

How do you envision pushing/reviewing a branch of 3 cleanly separated commits (say: write failing test, fix code, refactor) into a repo with a fast-forward/no-merge policy? The end result should of course be 3 commits, but review history should not be lost.

1) push 3 commits (author)

2) push 3 commits + 1 review commit (reviewer)

or even 2a), + 3 interleaved review commits, might be needed if the final refactor removes something.

then

3a) force-push 3 commits with the review comments applied (you mentioned --force is supported)

3b) or push 3 + 1 + (worst case 3) fixup commits, then a squash later?

If 3a), does pico have the concept of patchsets like gerrit, so the state 2) can be retrieved later?

PS: ... or even 2c, if the line I am commenting on is removed in patch 2 I would need to push a whole "review tree" (or fix conflicts in b and c):

   a -- b -- c -- review-c
    \   \
     \   `-review-b
      `- review-a

i really am a fan of what the pico.sh folks are doing. their ssh, cli-centric tools really speak to me.

I recently switched to neomutt and offlineimap/isync as my email client. I tried really hard after that to get a setup going so that I could accept git patches mailing list wise. I had to figure out how to set up a keyboard macro with just the right incantation[1] of b4[2]. I realized accepting patches meant my friends would also have to learn (neo)mutt if I wanted them to accept mine. It was really difficult. I can't imagine asking my friends to do that and collaborating with them. (I still like mutt though and still use it as my main client.)

By the way, good luck getting that set up to work on Windows, which a large population of developers use because of their work laptops (or because they simply prefer the interface!).

I made a script[3] that makes it easy to accept patches using an fzf interface, as a sort of reply to git-send-email[4]. I made sure to get it to work on Windows as well.

I kind of think I might like this better. My script only involves some setup of two other third-party tools to accept a patch, but this feels a little cleaner.

1: https://git.sr.ht/~skin/dotfiles/tree/main/item/dot-muttrc#L...

2: https://github.com/mricon/b4

3: https://git.sr.ht/~skin/git-receive-mail/

4: https://git-send-email.io/

This looks kind of small and homely and is obviously designed to appeal to a certain niche, which is nice. But the problem with a lot of "alternative code hosting" tools like this, IMO, is that they aren't actually that good for code review. This really dulls their appeal. What's the point of setting all this up if I don't read the patches?

If you are only accepting 1 patch a year, then the reality is anything will work. Email, uploading .patch files to a bug tracker, GitHub, whatever. But if you're doing review and managing a dozen active patch sets at once with people who are asynchronous to you, then you need something better than that. Let's say 5-10 active contributors. That's where projects actually tend to struggle.

There's this book called "Rethinking UI" and one of the first things it talks about is to write down features for your system, because the user interface comes from features. You can't design the UI without laying out a list of features. What features do I need in a code review tool? The two most important ones IMO are:

1. Code review is iterative, so a good feature is being able to see the history of a change as it is iterated on.

2. It's normal to have many patches in flight (your own + others). So, it's very useful to be able to quickly find things in a particular state: you need to review it (patch from someone else), you need to update it (patch you wrote and that got reviewed), it needs to be merged.

Extra:

3. It should be easy to safely integrate a change when it's ready.

Most tools are very bad at these core ideas:

- Almost no actual mainstream review tools, or modern pop-up clones, ever include "git range-diff" in their repertoire of tools. range-diff is essential for many projects to do iterative review, and tools like Linux's b4 automate them. I won't include it all here, but I wrote about this review style elsewhere: https://gist.github.com/thoughtpolice/9c45287550a56b2047c631...

- Most tools fall apart at "What state is this in." For instance, in GitHub it's impossible to tell what state anything is in, except "Can be merged" or "Cannot be merged." For instance, do I need to do another review on this PR after I did one before, and a coworker did one too? I have to go and look to see if everything was addressed properly. Tools like Gerrit have a more granular concept called "The Attention Set" which formalizes the concept of "Do I need to do something?" because it shows you when you need to take an action, like re-review or merge a patch.

git-pr doesn't really seem to make those core problems any easier.

Your approach sort of sidesteps these, these because you're expected to apply code manually and view it in your own editor. You could range-diff on your own. Part of the argument here goes back to the argument that best thing to do is sit in your editor -- but with a good review tool, you can do lots of review purely from your tool with no editor involved! I did tons of code review with Gerrit every day without ever opening my editor for 99% of it.

A semi-related thing some people say is "Well, in the Linux kernel style you can just send a pull request through any medium", while GitHub and these other tools use a specific interface. The problem is you still need state to track the state of the work. That's required (it's one of my features!), notably so you can look at the change evolution and see if it's ready to merge. If I tell you "Please merge my branch from https://example.com/foo.git with tag xyz-123" that's technically a "pull request" like you would send to Linus, but understanding the actual state that PR is in is impossible without a lot of extra knowledge that a third party tool formalizes (even if poorly.) b4, the Linux kernel patch series tool, has a ton of stuff for things like this like digging up the right email threads to do diffs between, showing the cover letter, etc.

And in the "How do Patch Requests work?" section, this sort of shows exactly the problem with this approach. I don't want to manually apply patches and run commands to merge it and push manually! I have 10 other patches to read after this one! Integrating things is why my tool is there! Why are steps 13 and 14 even necessary, for instance?

Gerrit does all 3 of the above properly and is a very, very powerful and productive tool when you get used to it.

Your approach does have a conceptual advantage which is that it focuses on the patch and not the "branch" as the unit of work. This is smart. So, if you keep going down this road and follow it to its logical conclusion, I think you'll tread some familiar ground. But I think realistically, you need to track actual state a patch is in, so that you can do things like range-diff it -- that would make the appeal of "Just write comments in the code" or whatever much higher because at least you can see when those comments get handled. You'll want to think about concepts like "Change IDs" as Gerrit calls them. Etc.

BTW, Gerrit does all if this, it uses this 'Git notes' approach you briefly mention, and it stores all its content in a Git repo too, no extra database. The web UI has tons of affordances, and everything you do in the web UI is just a commit in the underlying repo. And you can interact with Gerrit entirely over SSH with pubkeys if you want; it looks like running normal commands e.g. `ssh austin@gerrit.foo.com gerrit review ...` -- in theory you could write a whole TUI. I strongly suggest spending some time with it, if you haven't.

This is another interesting approach:

https://blog.sesse.net/blog/tech/2024-07-15-13-04_pull_reque...

Nifty, but it seems like this would lose commit message content and history entirely during the course of the review since you have to submit a single patch that gets applied, rather than publishing commits to a branch that gets merged. Am I understanding correctly?

How does the data backend for this look like? Does the review live after the PR being merged?

One of the required features of a review flow is having a way to look at a patch, understand the reasoning behind it, and the thoughts of people that reviewed and accepted it.

This is amazing!

I found the text a bit too reference-y, as in giving too much theoretical background, while what I'm actually looking for is workflow breakdown. The demo video at the top of the page[1] demonstrates it beautifully and I recommend you go give it a watch.

This is so slick. It's amazing to see how well git works when used in the way Linus intended. It seems to be missing some fundamentals (readme.md, signing, ssh key rotation), which I might try contributing to get my feet with :)

Gerrit allows you to see patchsets as they are applied on the same merge request. What are exactly the differences? It looks to me like similar to what you would do with Gerrit.

Not sure what I get from this that I won't from Gitea, and that doesn't need any adaptations to interfaces and if I want I get some basic project tracking tools and so on.

Would be even nicer if the command could be simplified (perhaps using a git alias) so that users don't have to go through the hassle of piping through ssh by hand.

I think permissions are a bit wonky? I could, as a random person, close some other project's PRs. How is the authz supposed to work?

This is extremely interesting. Add federation and you have a decentralized GitHub

Interesting, unfortunately format-patch does not support merge commits though.

workflows can be as slim and efficient as this: https://news.ycombinator.com/item?id=37086022

What about status checks and workflows?

wow, ty, this is brilliant!

GitHub's greatest win has been convincing everyone that "pull request" means having a web interface for code review as well (conflating sharing code with reviewing it) and can only be done by creating accounts in websites; and that patch-based workflows can only be done through email.

They even convinced people that repository clones are called "forks" when they have a web interface but not when they're local.

I like that this project is trying to remove those misconceptions.

Of course if the contributor already has their own publicly available repository, then they can send you a pull request through HackerNews if they want.

    Hey I made some performance improvements, they are at https://example.com/git-pr.git on branch `improvements`.

That was a pull request. You can check out changes with `git pull https://example.com/git-pr.git improvements` and review them.

I've also done ad-hoc patches through Slack, using `git diff` and `git apply` but the idea is the same.

And yes I've also done stuff like this but with just `git push` instead of `git format-patch | ssh` (you want to look at pre-receive hook) messing around with friends on IRC. The problem is not how possible or easy it is, the problem is "just" gaining traction and having a good plan for moderating The Stuff People On Internet Will Upload.

See GitTorrent for another (unrelated) example of a good idea that never gained traction.

meanwhile the equivalent process in svn is simply "svn copy" followed by "set permissions".

i feel like branch permissions in bare git repos should be a thing already. (rather than, say, having to rely on third-party providers implementing it into their centralised-git web service)