Git without a forge

Original Article ↗ Hacker News Discussion ↗

Maintainers wary of GitHub-style “forges” argue that git’s original, decentralized model—direct repos, email patches, bundles, and lightweight tools like Fossil or static HTTP hosting—is enough for collaboration without mandatory accounts or lock-in. Others counter that web forges, CI, and integrated issue trackers massively improve usability and code review, especially at scale, even if they centralize power and raise spam and privacy concerns. The exchange highlights a trade-off between contributor convenience and project autonomy, and between standardized, popular workflows and bespoke setups that deliberately filter who is willing to contribute.

Integrated tools and Fossil vs Git

  • Several commenters praise Fossil for bundling wiki, issues, forum, and web UI in a single binary that can serve over SSH/HTTPS or locally.
  • Workflow differences from Git: repo separate from work tree, auto-sync on commit, auto-staging of modified files, different status defaults. Some find this convenient; others say lack of an explicit staging area would be a deal-breaker.
  • A key complaint about Fossil is hostility to rebasing; some would switch entirely if rebase workflows were supported. Others see its built‑in extras as “cruft” compared to best‑of‑breed standalone tools.

Email vs forge-based workflows

  • Strong split on email-driven workflows (git send-email, SourceHut-style).
  • Critics (including people working with Linux-style email workflows) describe them as painful: hard to know base commits, awkward review/CI, poor tracking of review state, per-person scripts and tooling.
  • Defenders argue email is a flexible, lowest-common-denominator substrate with powerful client-side tooling (b4, Patchwork, various MUAs), and that forges simply centralize different pain points.
  • Some note many of the author’s complaints about git-format-patch can be mitigated with options like --base, mbox export, and git am, but acknowledge this depends on having a “competent” MUA, which many people lack.

Accounts, identity, and barriers to contribution

  • The need to create forge accounts is widely acknowledged as real friction; some have even stopped contributing rather than accept GitHub’s login/phone/2FA requirements.
  • Others counter that if you’re willing to spend hours on a patch, minutes to create an account are negligible.
  • Email also needs an account, but most people already have one; some self-host email and consider that lower-friction and more privacy-respecting than OAuth / “login with X”.
  • Federated identity or forge federation (Forgejo, Gitea, ActivityPub ideas) is seen as promising but raises spam and operational concerns.

Decentralization, monoculture, and hosting choices

  • Several agree with avoiding GitHub to resist monoculture and single high-value targets; others dismiss this as aesthetics or “goth subculture” but are challenged for ignoring the anti‑monoculture rationale.
  • Commenters emphasize that decentralization is achievable today: self-hosted Gitea/Forgejo, GitLab, or static repos over HTTPS, often with low effort.
  • Some run fully static, read-only Git over HTTP plus simple hooks; others imagine pure client-side gitweb‑like viewers using JS/WASM or static site generators.

Security, git bundles, and trust

  • One commenter worries about git bundles as arbitrary repo archives containing executable hooks; others clarify bundles only include packable objects—equivalent to git clone—not hooks.
  • The article’s security reasoning is criticized as underestimating the value of wide replication: many public clones on diverse forges are seen as stronger protection against history tampering than a single self‑hosted machine.

CI, automation, and why people still like forges

  • Some emphasize that forges are attractive mainly for integrated CI, deployment, and backup/portability; GitLab/Gitea + runners are cited as easy, reproducible DevOps setups compared to ad‑hoc scripts/cron.
  • Others prefer minimal setups and accept losing built‑in issues/PRs/CI to avoid complexity and dependence.

Contributor friction and “open source but not open contribution”

  • The author’s multiple non-forge submission paths (email, URLs, bundles) are viewed by some as confusing and a barrier that discourages contributions, especially from casual or non‑“git nerd” developers.
  • Others say this friction can be desirable: it filters drive‑by or entitlement‑driven contributions and suits “open source but not open contribution” or low‑support projects.
  • There’s debate over whether deviating from dominant forge workflows is “obscurantist” or simply a legitimate choice to optimize for maintainer comfort over contributor count.