Git-PR: patch requests over SSH

Original Article ↗ Hacker News Discussion ↗

A new tool called Git‑PR proposes handling pull requests as plain git patch sets sent over SSH, keeping code review entirely inside developers’ local editors instead of web UIs. Commenters compare this approach with GitHub-style browser workflows, traditional email-based patch review, and systems like Gerrit, debating trade-offs in usability, scalability, state tracking, and review features such as range-diff and patchsets. Many see Git‑PR as an appealing, lightweight option for self-hosted or small projects, but question whether it can match the richer workflow management needed for larger, high-traffic codebases.

Overall reception and target audience

  • Many commenters like the “all in git + SSH + editor” philosophy and CLI focus, especially for small/self‑hosted projects.
  • Others see it as niche; they expect most organizations to stick with GitHub/GitLab and IDE integrations.
  • Authorial comments frame the target as “self‑hosted hacker enthusiasts” who want something between git send-email and a full forge.

Workflow vs existing tools

  • Advocates highlight a simple contributor flow: clone → change → git format-patch | ssh host pr create …, with no web accounts, forks, or extra clients.
  • Critics argue modern forges already make PR/MR creation quick, and that this still requires a centralized service and SSH setup.
  • Some note that Gitea/Gogs are already easy to self‑host with similar dependencies; others wish for a common PR API across forges.

Comparison to email workflows

  • Supporters position git‑pr as a friendlier alternative to mailing‑list workflows, which require mail setup, list management, and special clients for smooth patch application.
  • Defenders of email say once configured, git send-email is fast, flexible, and keeps you in your mail client with good inline replies.
  • Others point out practical email pain points: bad default clients, wrapping issues (e.g. webmail), IP leakage, and complex headers for threading.

Code review quality, scale, and state tracking

  • Several commenters worry git‑pr doesn’t yet address hard problems of large‑scale review:
    • Tracking patch state (“who needs to act next?”).
    • Iterative review and seeing differences between patchsets (range‑diff).
    • Preserving review history across force‑pushes.
  • Gerrit is repeatedly cited as a “gold standard” with change IDs, patchsets, attention sets, and purely git‑backed state; Phabricator is also mentioned positively.
  • Project maintainers acknowledge gaps, mention event logs and a patchset concept, and discuss adding patch revisions, cover letters, and range‑diff‑style workflows.

Usability, tooling, and limitations

  • Some testers found the docs unclear on how external contributors actually submit PRs; maintainers say missing pieces will be added.
  • Concerns raised: permissions/authz (e.g., who can close PRs), backend data model, whether reviews persist after merge, license clarity, merge‑commit support limits of format-patch, and lack of integration with CI/status checks.
  • A few suggest aliases or wrappers to hide the explicit format-patch | ssh pipeline and smoother “review without touching my dirty working tree” flows (e.g., via worktrees or patch editing).