Git without a forge

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.