Lore is an open-source version control system designed for scalability — large repositories, long histories, and monorepo workloads where Git's performance characteristics start to hurt. The project drew significant attention on Hacker News not because Git is failing tomorrow, but because a growing slice of engineering orgs is hitting limits that Git was never optimized for.
This article is not a Lore review or a prediction that Git will be replaced. It is a systems read: what breaks at scale, why Git's design choices cause those breaks, and what a purpose-built VCS might prioritize differently.
Where Git starts to strain
Git excels at distributed workflows, branching, and repos that fit comfortably in memory on a developer laptop. Strain appears when any of these grow large:
- Repository size — binary assets, generated code, or years of history push clone and fetch times from seconds to tens of minutes.
- File count — monorepos with hundreds of thousands of files slow status, checkout, and index operations.
- History depth —
git log, blame, and bisect over millions of commits become expensive on commands that feel instant in small repos.
The pain is operational. CI pipelines wait on shallow clones that still transfer gigabytes. Developer laptops swap during git status. Code review tools timeout listing diffs across unrelated monorepo paths.
Think of Git like a filing cabinet that works perfectly for a single office. Stack ten years of every department's records into one drawer, and the same cabinet becomes the bottleneck — not because it was badly built, but because the load profile changed.
Design choices that create the ceiling
Git stores snapshots as content-addressed objects linked in a directed acyclic graph. Deduplication is excellent. But several properties follow:
Full history by default. Every clone carries the entire graph unless you use shallow clones or partial clone filters — features that exist but complicate tooling assumptions.
Index scans the working tree. git status compares the index to the filesystem. In a 500k-file monorepo, that comparison dominates interactive workflow latency.
No native partial checkout semantics at the protocol level. Sparse checkout and submodules patch around monorepo needs; they do not redesign the core model for "I only care about this subtree."
Merge and rebase complexity scales with conflict surface. Large repos with many concurrent contributors increase the probability of painful merges independent of Git's raw speed.
These are not bugs. They are trade-offs Git made for distributed open-source development in the 2000s. Enterprise monorepos at 2020s scale are a different problem.
What a scalable VCS might optimize
Projects like Lore typically bet on different priorities:
- Partial visibility — fetch and work with a slice of the tree without materializing the whole repo.
- History segmentation — lazy history loading instead of all-or-nothing clone depth.
- Metadata indexing — fast queries over file paths, authors, and change types without walking the full object graph.
- Server-assisted operations — move expensive computation to infrastructure designed for it, not every laptop.
The pattern mirrors databases: you do not run analytics on a production OLTP schema without an index strategy. Git at monorepo scale is OLTP without the indexes your query patterns now require.
Version control at scale is a storage and indexing problem wearing a collaboration interface.
Git is not going away — but the fringe is real
Replacing Git org-wide is a multi-year migration with tool-chain dependencies: CI, code review, IDE integration, hosting platforms. Lore and similar projects target teams already feeling acute pain and willing to experiment.
For most teams, the near-term playbook remains Git plus mitigations: partial clone, sparse checkout, history truncation for CI, and monorepo tooling (Bazel, Nx, internal virtual filesystems) that reduce how often Git sees the full tree.
The Lore conversation matters because it names the ceiling explicitly. When your clone time exceeds your coffee break, the problem is architectural — not something another .gitignore entry fixes.
| Symptom | Common Git mitigation | Architectural fix direction |
|---|---|---|
| Slow clone | Shallow clone, partial clone | Lazy history, server-side fetch |
| Slow status | Sparse checkout, skip-worktree | Indexed working-tree diff |
| Huge monorepo | Submodules, split repos | Native partial-tree semantics |
| Binary bloat | Git LFS, external storage | Content-type-aware storage layer |
What this means for builders
Measure before migrating. Track clone time, status latency, and CI fetch duration. If none exceed a few minutes, Git mitigations are cheaper than a VCS migration.
Treat monorepo pain as a design signal. When developers avoid commits because status is slow, the repo structure or tooling — not individual discipline — is the problem.
Watch purpose-built VCS projects for indexing ideas. Even if you stay on Git, their approaches to partial visibility and lazy history inform how you configure partial clone and sparse checkout today.
Plan tool-chain cost for any switch. A faster VCS that breaks your review bot, CI cache keys, and IDE integration is not a win on net.
Conclusion
Lore enters a conversation Git's success created: version control that scales to every laptop on Earth works until your tree, history, or binary surface area outgrows the assumptions baked into the original design. Understanding where those assumptions bite — and what a system optimized for monorepos would prioritize instead — helps you decide whether you need a configuration tweak, a monorepo tool layer, or something more radical. Most teams land on the first two. The third is worth watching.