If I could make my own GitHub

Original Article ↗ Hacker News Discussion ↗

DIY forges and LLM-assisted cloning

  • Several comments argue “doesn’t sound too hard”: with modern LLMs, cloning or reimplementing tools (even closed-source apps) is seen as feasible weekend projects.
  • Others note scope creep: what starts as a weekend project can turn into ongoing work, and “foundational” tools are hard to generalize beyond one’s own needs.

Existing alternatives and self‑hosting

  • Many point out existing self-hosted options: GitLab, Gitea, Forgejo/Codeberg, cgit, Sourcehut, Tangled, Radicle, Grasp, Fossil, Gerrit.
  • Critics argue most still mimic GitHub’s model and inherit its flaws, or suffer from poor UX, complexity, reliability issues, or missing features (e.g., private repos in some decentralized designs).
  • Some like Sourcehut’s minimal, email-centric approach; others want just barebones git hosting with most “bells and whistles” removed.

PR and review workflow problems

  • Strong dissatisfaction with GitHub-style PRs: noisy, UI hides discussion, comments prioritized over code, hard to track revisions, and stacked/iterative review is clumsy.
  • Gerrit’s change-id-based, multi-round review (with comments persisting across revisions) is praised, along with its richer approval states (e.g., -2…+2) and customizable labels.
  • There’s debate over whether approval should be strictly boolean vs multi-level (“partial approvals”, domain-specific signoffs, “approve with suggestions”).

CI, pre-commit hooks, and local vs remote

  • Some want enforced pre-commit/“pre-push” CI run remotely on the forge to catch issues before PR churn.
  • Others push back: conceptually post-push, bad for workflows that commit broken checkpoints, and can be slow; local test commands or tools like pre-commit are preferred.
  • Desire for CI definitions that run identically locally and in CI; frustration that GitHub Actions are hard to replicate offline.

Decentralization, control, and business model

  • Concern over centralizing on GitHub and corporate control (especially post-acquisition), censorship of issue discussions, and AI-driven priorities over reliability.
  • Acknowledgement that running SaaS is expensive, pushing platforms to optimize for large customers and vendor lock-in (e.g., keeping review/issue metadata off-git).

What a “better GitHub” might prioritize

  • Strong UX and reliability are seen as more critical than novel backends.
  • Features people want: stacked PRs, better integration of reviews/issues into git history, offline/“local-first” issues and reviews, simpler hosting modes, flexible review rules, easier private repos, and avoiding YAML-heavy CI.
  • Some note that git already supports partial clones, hooks, and notes, implying more could be built on existing capabilities.