Git-PR: patch requests over SSH

Original Article ↗ Hacker News Discussion ↗

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