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.
- 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.
It does seem like it would be hard to support inline comments properly outside of an email quoting context without editor integration.
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.