Twenty years is nothing

Original Article ↗ Hacker News Discussion ↗

Version control has evolved from lock-based, centralized systems like SourceSafe and CVS to Git’s distributed, history‑everywhere model, which many see as a transformative but imperfect plateau. Commenters weigh Git’s speed and robustness against its confusing UX, poor handling of very large or binary-heavy repositories, and lack of semantic or AST‑aware history, pointing to alternatives such as Mercurial, Fossil, Pijul, jj, and CRDT-based designs as attempts to address these gaps. The exchange also highlights how implementation choices (e.g., Rust vs. Python), workflow patterns (rebasing, stacked commits), and hosting platforms (GitHub vs. self-hosted) shape both tool quality and developer culture.

Implementation languages and “written in Rust”

  • Repeated debate over why projects advertise “written in Rust.”
  • Supporters say language choice signals:
    • Memory safety and speed without GC.
    • Static, self-contained binaries and smooth tooling.
    • A developer culture that cares about correctness and performance.
  • Skeptics see it as weak marketing: if “written in Rust” is the headline, maybe there’s little else to differentiate.
  • Some note language is predictive of project style and ecosystem fit (e.g., easier to contribute if you know Rust/Go vs Python).
  • Critiques of Python/JS for performance and long-term stability; Go noted as similar to Rust in distribution but not in type/ownership guarantees.

Pijul, patch-based VCS, and CRDT ideas

  • Pijul and Fossil highlighted as true Git alternatives with different designs; jj and Sapling seen more as improved Git/Mercurial interfaces.
  • Pijul’s author explains:
    • Design is patch/CRDT-based; conflicts are part of the model.
    • Data structures were designed “like theorists,” then optimized.
    • A custom Rust key–value store (Sanakirja) enables fast, generic, mmap-friendly storage and efficient forking, outperforming LMDB in their benchmarks.
    • Rust chosen pragmatically for low-level control without C++’s debugging pain; might choose Zig today due to language evolution.
  • Some argue patch-based VCS can be faster than snapshot-based Git for large repos, conflicts, blames, and binary files.

Git strengths, weaknesses, and workflows

  • Widely praised for:
    • Speed compared to older tools.
    • Distributed workflow and offline commits.
    • Flexibility and powerful data model.
  • Criticisms:
    • CLI UX is confusing; concepts leak internal implementation.
    • Rebase, history rewriting, and stacked-commit workflows are hard; tools like Gerrit/Graphite/jj try to mitigate.
    • Git stores snapshots, not explicit change history; file renames/splits and big refactors are hard to track.
    • No empty directories; history of file splits/merges and semantic moves is weak.
    • Git LFS seen by some as fragile and operationally awkward.

Centralization, history size, and partial clones

  • Debate over whether full-history local clones were “unthinkable” 20 years ago; some recall CVS/SVN plus local scripts and large-enough disks, others emphasize network and storage limits of the time.
  • Point that DVCS implies a practical cap: repo history must fit on the smallest dev laptop.
  • Some argue most organizations are de facto centralized and would benefit from hierarchical/subordinate clones: partial history, partial trees, but still local branching and commits.
  • Newer Git partial clone and sparse-checkout features mentioned as partial solutions.

Binary assets and non-text projects

  • Git’s text-centric model works well for most software, but:
    • Games, chip design, and media pipelines still favor Perforce or SVN due to large binaries.
    • Git LFS criticized as buggy, operationally complex, and requiring extra server components.
    • Desire for VCS that understands binary formats (e.g., semantic diffs for images) and large file storage natively; Pijul claims native binary support.

Semantic, AST-aware, and CRDT-based futures

  • Multiple commenters suggest:
    • Version control over ASTs or domain-specific structures instead of raw text.
    • Better diffs/conflicts that understand moves, renames, refactors.
  • One proposal: a Git successor storing character-level CRDT histories, supporting real-time collaboration and semantic commits; open issues include conflict surfacing and data deletion (secrets).
  • Others argue such granularity may add noise and complexity; commits as human-chosen checkpoints remain valuable.

Historical tools and perspective

  • Extensive reminiscences of VSS, ClearCase, Perforce, CVS, SVN, RCS, BitKeeper, and ad hoc zip/tar “versioning.”
  • Lock-based centralized systems (VSS, some ClearCase/Perforce setups) remembered as painful but once considered “professional”; open-source workflows with CVS/SVN were seen as ahead of many enterprises.
  • General sense that each generation thought its tools were good until the next major step (SVN, then Git/DVCS) exposed their limits.

Will anything replace Git?

  • Some think Git is an evolutionary plateau; successors would need:
    • Full Git compatibility and transparent use on existing repos.
    • Simpler UX and better semantics (renames, AST-aware ops, stacked commits).
    • Better handling of large repos and binaries.
  • Others expect eventual displacement, citing the long history of VCS churn; still, Git’s network effects and “good enough” status may keep it dominant for a long time.