Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

Hacker News Discussion ↗

A YC-backed startup pitching Diversion as a “cloud‑native Git alternative” drew mixed reactions from developers. Many agreed Git’s UX, handling of large binary assets, and suitability for game development and other media-heavy workflows leave real gaps, but criticized Diversion’s Git-bashing pitch, centralized cloud-only design, and lack of open source or self‑hosting as significant trust and adoption barriers. The thread converges on the idea that there is room for new version control models—especially for large assets and non‑coders—but success will hinge on clear differentiation from Git/Perforce, strong offline and security stories, and credible governance of the core technology.

Positioning and Target Market

  • Many argue Diversion is really competing with Git hosting and Perforce/Plastic, not Git itself.
  • Strong suggestion to focus the pitch on game studios, large binaries, and non-programmer workflows rather than “Git is bad”.
  • Several see potential specifically as a simpler, cloud-first Perforce alternative for small/medium game studios and creative teams.

Git: Criticism vs. Defense

  • Critiques:
    • Git is conceptually complex and error-prone for non-experts; commands like push --force and reset --hard are seen as “footguns”.
    • Poor UX for non-coders (artists, data scientists, etc.).
    • Weak native support for large binary files and very large repos; Git LFS seen as clumsy and fragile at scale.
  • Defenses:
    • Actual data loss is hard due to reflog and distributed clones; the “destroyed month of work” story is widely challenged and later softened.
    • Many issues attributed to misconfiguration, poor training, or bad workflows, not Git itself.
    • Existing features (shallow clones, filters, fsmonitor, monorepo tooling) alleviate some scalability concerns.

Cloud-Native, Centralization, and Offline Work

  • Diversion’s design (serverless, REST API, always-in-cloud state) is praised for scalability, real-time sync, and easier CI/cloud-dev integration.
  • Critics see “cloud-native” as:
    • A regression from offline-capable distributed VCS.
    • Risky single point of failure and a poor fit for flaky networks (remote work, airplanes, some regions).
    • Potential vendor lock-in, especially on AWS, and problematic for studios with strict on‑prem/security requirements.

Security, Openness, and Trust

  • Data is encrypted in-transit/at-rest but not end-to-end; some consider this a blocker for sensitive code.
  • Many insist they won’t entrust core source control to a closed, cloud-only startup; strong pressure to open-source (ideally copyleft) and support self-hosting/private cloud.

Desired Features and Suggestions

  • Strong interest in:
    • First-class large binary support, file locking (esp. across branches), partial checkouts, and fast big-repo operations.
    • Better GUIs and “guardrails” for non-experts, opinionated workflows, and simplified concepts vs Git.
    • Richer integration: CI-friendly CLI, semantic/AST-level diffs, integrated hooks, patch stacking, and broader document/config versioning.
  • Overall tone: skepticism about the current pitch and trust model, but clear recognition that VCS—especially for binaries and non-developers—remains an open problem worth tackling.