A Git story: Not so fun this time

Overall reception and historical value

• Many readers praise the piece as unusually complete, detailed, and engaging; several say it’s the best history of Git they’ve read.
• Some point out minor factual or presentation issues (e.g., early GitHub screenshot via Wayback, missing credit for a long HN quote) but still regard it as high‑quality work.
• Multiple commenters request more similar “software history” articles and share related resources/newsletters.

BitKeeper, Mercurial, Fossil, and other VCSes

• Several people reminisce about BitKeeper, describing Git as a spiritual rewrite but with a worse CLI and different trade‑offs.
• Mercurial is remembered fondly, especially for better Windows support, but seen as losing out to Git’s network effects.
• Fossil is praised by some for its integrated model and branching/merging UI, but criticized by others as less collaboration‑friendly (per‑repo user accounts) and niche.
• Other systems (Perforce, ClearCase, Plastic SCM, custom DVFS/DVFS‑like tools) are brought up for specialized needs, especially binaries and game development.

Git’s dominance and likelihood of replacement

• Many consider Git’s position extremely entrenched, likening it to ASCII: extensions are plausible, full replacement unlikely.
• The author suggests that, like x86 vs ARM, changes in how code is produced (e.g., AI) could open space for something new.
• Some argue a Git successor would need: better scaling for giant monorepos, first‑class binary handling, easier multi‑remote setups, and more ergonomic workflows.
• Others think replacements will remain niche, built in‑house at huge companies, while Git remains “good enough” for everyone else.

Technical critiques and defenses of Git

• One long critique calls Git a “tarball server” rather than a full SCM, citing:
  • Heuristic rename detection instead of recorded renames.
  • Lack of per‑file history graphs and per‑file commit comments, hurting debugging and annotation fidelity.
  • Repository‑wide DAG causing distant merge bases vs per‑file GCAs.
  • Submodules as poorly designed compared to true multi‑repo/mono‑repo unification.
  • Performance issues on very large repositories.
• Defenders counter that:
  • Tracking states instead of operations is a deliberate design trade‑off; sophisticated change tracking (splits/merges of files) is complex and tool‑dependent.
  • Git has significantly improved scalability (sparse checkout, partial clone, VFS/Scalar‑style tooling) and is workable even for huge codebases, though some tooling remains proprietary.
  • Squash/rebase workflows are considered a feature by many, enabling cleaner history across multiple releases and hotfixes.

Monorepos, binaries, and workflow boundaries

• There’s extensive debate on whether Git “should” handle large binaries.
  • Some argue DVCS is fundamentally for text/source; binaries belong in other systems or tools like git‑annex or specialized SCMs.
  • Others insist real‑world projects inevitably mix code with small images or occasional large files, and Git should do better at selective fetch and deduplication.
• Sparse checkout and partial clone are seen as progress but not equivalent to fully demand‑loaded monorepo systems integrated with build tools.

Licensing, CLAs, and governance

• Discussion around a modern Git‑UI tool backed by a large company focuses on its Contributor License Agreement.
  • One side argues the CLA effectively allows the company to ignore Apache‑2.0’s constraints and change licensing unilaterally.
  • Others emphasize that copyright is not transferred, that Apache is already permissive, and that the CLA’s primary purpose is asserting contributor ownership.
  • The Developer Certificate of Origin (DCO) is cited as a lighter‑weight alternative accepted by many legal departments.

BitKeeper licensing and reverse‑engineering controversy

• Commenters revisit BitKeeper’s restrictive license (especially limits around using it while working on competing VCS code) and note parallels with other niche tools that sparked open competitors.
• There is sharp disagreement about how a BitKeeper‑compatible pull tool was developed:
  • One side maintains it was done via simple, legal protocol inspection (telnet to BK port, SCCS understanding).
  • Another side claims network snooping of a user’s BK traffic was involved and labels that unethical.
  • Others reply that network sniffing for reverse engineering is common and legal; they see creating an open alternative as an overall positive despite any discomfort from the original vendor.

GitHub, “official” Git sites, and early ecosystem

• Clarifications:
  • GitHub is not formally the Git project’s governing body, though it did host the main site/docs for a while and its staff helped set up git‑scm.com.
  • Today the canonical Git repo is on kernel.org with various mirrors.
• Early GitHub UI screenshots in the article were updated after commenters showed that missing CSS in archived captures distorted how the original site actually looked.

Impact of Git and GitHub on open source

• Several commenters credit Git and GitHub with massively accelerating the scale and practicality of free software development.
• Some speculate that without Git (and GitHub), today’s level of open collaboration would be much harder to sustain.