If I Could Make My Own GitHub (5 minute read)
A developer argues that modern code forges like GitHub have lost sight of developer needs and proposes a reimagined system that better integrates version control clients with repositories.
What: An opinion piece critiquing how GitHub, GitLab, and other code forges have built centralized workflows on top of git's decentralized design, proposing an alternative that includes pre-commit remote hooks, flexible PR approvals, stacked PRs as first-class features, and smaller hosting units that can run on devices like Raspberry Pis.
Why it matters: This articulates growing developer frustration with GitHub's direction and proposes concrete alternatives at a time when the platform's quality concerns are driving projects to seek alternatives, suggesting the current monolithic forge model may be breaking down.
Takeaway: Explore alternative version control systems like JJ (Jujutsu) and evaluate whether your team actually uses most of GitHub's features or just needs better git workflows.
Deep dive
- Modern forges are disconnected from git's original design as a decentralized system for kernel development using email patches, but developers now just use it for centralized pull/push workflows where all important features live in the forge itself
- Current PR workflows provide feedback too late—developers want validation before commits are pushed, not after, through enforced pre-commit hooks that run CI/CD remotely on the forge
- Binary approve/reject PR models don't match reality where code review often involves nuanced decisions like "fine for now, revisit later"—Gerrit's multi-level approval system is a better model
- Requiring approval on every change wastes senior engineer time on trivial PRs, especially with LLMs available to assess risk—approval requirements should be customizable based on maintainer status and change complexity
- Stacked PRs make code easier to review by breaking changes into logical units but aren't first-class citizens in current forges, requiring third-party tools to manage
- Forges suffer from feature creep—issue tracking makes sense, kanban boards and wikis probably don't—leading to maintenance burden for rarely-used features that can't be removed once adopted
- Standard forge hosting units are too large (GitHub Enterprise, GitLab) with many moving parts when organizations should be able to run on clusters of small devices like Raspberry Pis
- Local repository clones should represent the entire project including PRs and issues, not just code, allowing developers to approve PRs and triage issues from their VCS client
- Storage should be optimized for always-online workflows with shallow clones by default and on-demand history fetching rather than cloning entire project history upfront
- GitHub Actions and similar CI/CD systems should be signed, content-addressed by SHA, and usable offline with local tarballs rather than requiring network access to third-party repositories
- The proposed solution combines JJ as the version control system with modern infrastructure concepts like object storage, shallow clones, and federation of small hosting units
- The author argues that only GitHub's declining quality makes this conversation worth having—previously the default was good enough that alternatives were "like sweet potato french fries" (never what you actually want)
Decoder
- Forge: A platform that hosts git repositories and adds collaboration features like pull requests, issues, and CI/CD (GitHub, GitLab, Gitea are examples)
- Four-eyes principle: Security practice requiring two people to review and approve changes before they're merged into the codebase
- Stacked PRs: Multiple dependent pull requests built on top of each other, allowing reviewers to see logical progression of changes rather than one massive PR
- Gerrit: A code review system originally built for Android development that uses a more nuanced approval model with multiple levels like +1, +2, -1, -2 instead of binary approve/reject
- JJ (Jujutsu): A modern version control system designed to be more user-friendly than git while maintaining compatibility with git repositories
- Shallow clone: Downloading only recent commit history instead of the entire project history, saving bandwidth and storage
Original article
Git is great at what it is designed to do, but what it is designed to do isn't the way most people are using it.