20 years of Git

Original Article ↗ Hacker News Discussion ↗

Learning Git’s internals and longevity

  • Commenters appreciate resources on Git internals and note how remarkably stable the core model has been for ~17 years.
  • This stability is framed as both a strength (backwards compatibility) and part of why the UI feels “grown” rather than designed.

Signing, $Id$, and content-addressable design

  • Several people have recently switched from GPG to SSH-based commit signing, citing easier setup, hardware-backed keys, context separation, and small, readable policy files.
  • CVS’s $Id$ keyword is missed; suggested workarounds use Git clean/smudge filters to inject version info (e.g., git describe) without breaking content hashes.
  • One long subthread debates GUIDs vs hashes: Git’s key idea is that object IDs are derived from content, removing the need for a central mapping. Others note that in practice, central hosting (e.g., major forges) still shapes usage.

Pre-Git ideas: hashes, Merkle trees, Nix, Unison

  • A 2002 design for GUID-addressed modules, manifests, and toolchains is presented; commenters connect it to Nix, Unison, Merkle trees, and content-addressable stores.
  • Discussion clarifies differences between random GUIDs and content hashes, and notes similar ideas in backup systems and blockchains.

Frontends and “post-Git” systems (jj, GitButler, others)

  • Multiple users strongly endorse Jujutsu (jj) as a Git-backed VCS with a revision-centric model: mutable working revisions, automatic tracking, simpler commands for split/squash/rebase, and better conflict handling.
  • GitButler and jj are collaborating with Gerrit on change-ids; debate centers on putting these in headers vs trailers for robustness and tooling compatibility.
  • Patch-based review (GitButler) and patch-theory systems (Darcs, Pijul) are discussed as alternatives to snapshot-based Git. Fossil is also mentioned.

Workflows, UX, and history

  • Many contrast mailing-list patch workflows with GitHub-style PRs: mailing lists treat commit messages and series structure as first-class; PR tools often don’t, leading to weaker history.
  • Git’s CLI is widely described as powerful but incoherent: leaky abstractions (index/staging), overloaded commands, bolted-on features (stash), and poor naming. Yet many still “love” it because the underlying model is clear once understood.
  • Some argue Git’s dominance was not inevitable: Mercurial, Monotone, Darcs, and BitKeeper all influenced the space. Others credit Git’s speed, C implementation, flexibility, and the Linux kernel + GitHub ecosystem for its win.

Limitations and future directions

  • Pain points: large/binary files, weak explicit rename tracking, and awkwardness for non-text or CAD-scale sources. Tools like git-annex, git-lfs, and external diffing are mentioned but seen as bolt-ons.
  • AI-first workflows (e.g., IDEs with chat histories and auto-generated changes) don’t map neatly onto current branch/commit patterns; some want less manual branching and no hand-written commit messages.
  • SHA-1 vs SHA-256: one side argues practical collision risk is negligible for scale; another notes that chosen-prefix collisions enable malicious replacements, motivating stronger hashes.
  • git worktree is highlighted as a “newer” feature that meaningfully improves day-to-day work compared to stashing and recloning.