Ask HN: Can we do better than Git for version control?

Hacker News Discussion ↗

Git’s dominance as a version control system is widely acknowledged, but many engineers argue it is far from ideal, especially in terms of usability, handling large binary assets, and supporting huge monorepos. Commenters point to alternatives like Fossil, Mercurial, Perforce, Pijul, Jujutsu, and Sapling, as well as UI layers and tools built on top of Git, as evidence that better workflows and models are possible. The prevailing view is that network effects and GitHub’s ecosystem make outright replacement unlikely in the near term, so most practical innovation is focusing on improved interfaces, smarter merges, and specialized systems for non-code assets rather than abandoning Git entirely.

Overall sentiment on Git

  • Many consider Git “good enough” and likely dominant for a long time due to ubiquity and ecosystem, not because it’s ideal.
  • Others argue it’s far from a solved problem: confusing UI, poor defaults, and some real architectural limitations.
  • Several comments note that Git replaced worse systems (RCS/CVS/SVN) and solved major problems, but itself now looks dated.

UX, mental model, and learning curve

  • Repeated complaints about confusing concepts and commands: commit vs push vs pull vs fetch, staging area, rebase, reflog, etc.
  • Some want a simpler “easy mode” with a small, safe command set (“save / update” style) and an “expert mode” for advanced operations.
  • There’s tension between “tools for professionals, complexity is fine” and “poor UX wastes time and is not justified.”
  • GUIs and higher-level tools (IDEs, desktop apps, TUI frontends, wrappers like Graphite, Magit, etc.) are seen as effective ways to tame Git.

Technical and architectural pain points

  • Large files and binary assets: Git LFS is seen as clunky and fragile; game dev and CAD workflows often prefer Perforce or SVN.
  • Very large monorepos: performance issues with status scans, history size, and many files; workarounds include virtual file systems, sparse/partial clones, and vendor-specific tools.
  • Conflict resolution: current merge algorithms are considered “fast but dumb”; limited modeling of conflicts (no “conflicted state” as first-class), hard renames, and lack of semantic understanding.
  • Storage model: snapshot-of-blobs vs patch-based; some argue patch-based systems (Darcs, Pijul) enable better merges and history reasoning.

Alternatives and new systems

  • Frequently mentioned: Fossil (integrated tickets/wiki, immutable history), Mercurial and derivatives (Sapling, internal Google systems), Darcs, Pijul, Jujutsu, Perforce, and domain-specific tools (e.g., Oxen for large AI datasets).
  • Some new tools stay Git-compatible at the storage/protocol level while offering new UIs or semantics, viewed as more adoptable than a clean break.

Hosting, centralization, and network effects

  • Git’s dominance is tightly coupled to GitHub and similar forges; discoverability and contributions suffer off-GitHub.
  • Alternatives like GitLab, Forgejo/Gitea, SourceHut, Codeberg, and Fossil hosting exist but struggle against network effects.
  • Federation between forges is mentioned as a possible way to reduce lock-in.

Future directions

  • Ideas raised: semantic diffs/merges, AST-based code storage, branch history as a first-class object, better physical-history tracking, editor-integrated move tracking, and more centralized-first workflows.
  • Unclear if any will gain enough momentum to displace Git; layering improvements atop Git is seen as the most realistic near-term path.