The Wrong Tool for the Job: What Git Borrowed From a Problem You Don't Have

The most useful tools in software pick a problem and solve it completely. That focus is what makes them so good. It’s also what makes them so bad at everything else. A tool’s strengths and its blind spots come from the same design decisions. You don’t get one without the other.

This is worth being honest about, because we adopt great tools as defaults and then quietly absorb the cost when our problem isn’t the one they were designed for. Git is the clearest example in our industry. It isn’t the only one.

A tool’s gift is also its cage

An eighteen-wheeler can haul forty thousand pounds across a continent without breaking a sweat. So why does anyone still drive a small car? If more capacity were strictly better, the truck would win every trip.

It doesn’t, because the things that make a semi great at hauling are the same things that make it miserable for a commute. The length and turning radius that let it carry a full trailer are what make it impossible to park outside a coffee shop. The air brakes and eighteen gears built for forty tons are dead weight on a school run. The fuel and maintenance that are just the cost of moving freight are pure waste when the only thing you’re moving is yourself. None of this is a flaw in the truck. It’s the price of everything that makes the truck good. The capacity that’s a gift on the interstate is a cage in a parking lot.

That’s the pattern. The assumptions a tool bakes in to be great at one job are the assumptions that betray you on a different job. The useful question is never “is this a good tool?” It’s “do I have the problem it was built for?”

The problem Git was built for

Git was written in 2005 to manage Linux kernel development. Keep that context in mind, because every design decision follows from it:

• Thousands of contributors who don’t trust each other. No central authority decides what’s canonical. Anyone can fork, and history has to be cryptographically verifiable so a malicious contributor can’t rewrite it.
• No assumption of connectivity. Contributors work offline and exchange changes asynchronously, originally over email, as patches.
• No single owner. There is no server that holds the one true copy. Every clone is a full, equal peer with the entire history.
• Coarse, batched collaboration. You work alone for a while, then publish a commit, which is a complete snapshot, for others to pull. Integration happens after the fact, through merges.

For that problem, Git is a masterpiece. Distributed, content-addressed, offline-first, tamper-evident, owner-less. It solved kernel development so well that it took over the world.

Now look at that list again and ask whether it describes your company.

The problem most software companies actually have

Inside a normal software company, almost every one of Git’s founding assumptions is false:

• You have a single owner. There is a canonical source of truth. It lives on a server you control, and everyone agrees it’s authoritative.
• Your contributors trust each other. They’re employees with credentials and permissions. You do not need a cryptographic defense against your own teammates rewriting history.
• Everyone is online, all the time. The offline-first, exchange-patches-by-email model solves a problem you don’t have.
• You want tight, continuous collaboration, not batched snapshots published after the fact. What you actually wish you had is closer to a Google Doc than to a mailing list.

So you’re using a distributed, owner-less, offline-first, distrust-by-default system to model a centralized, owner-ful, always-online, high-trust organization. Every one of those mismatches shows up as daily friction: the branch-and-merge ceremony, the merge conflicts that exist because integration was deferred, the full history every laptop has to carry, the inability for two people to edit the same file at the same time without a fight. None of that comes from version control in general. It comes from this version control, the one built for a problem you don’t have.

Why “just use multiple repos” makes it worse

Here the mismatch compounds. Git’s data model strains under very large repositories, so the ecosystem’s accumulated advice became: split your code into many repos. Microservices, one repo each. Shared library? Its own repo. This gets sold as good architecture. Mostly it’s a workaround for Git’s scaling limits dressed up as a principle.

The costs are real, and teams pay them every day:

1. Changes stop being atomic. A cross-cutting change, like renaming an API and updating its three callers, now spans four repos and four pull requests that can’t merge together. There is no single moment where the system is consistent. You’ve traded one coherent change for a distributed transaction with no coordinator.
2. History fragments. There’s no longer one timeline that tells you what the system did and when. To understand a single user-facing change, you reconstruct it across repos by correlating timestamps and commit messages.
3. Dependency hell becomes internal. Your own libraries now have versions, and your own services pin different ones. You’ve imported all the pain of external dependency management for code you wrote yourself.
4. Refactoring dies. The large, healthy, cross-cutting cleanup that keeps a codebase alive becomes so procedurally expensive across repo boundaries that people stop doing it.

The companies that can afford to went the other way. Google and Meta run one giant monorepo. They could only do that by building enormous custom tooling on top of or in place of Git to make it survive at that size. That fact is the whole point. When the organizations with the most engineering resources on earth conclude the right answer is one repo, and the only thing stopping everyone else is that the tool can’t handle it, then the tool is what’s holding everyone back.

Why GitHub keeps hitting the same wall

GitHub is one of the great products of our era, and it is built on a contradiction. It is a centralized collaboration platform wrapped around an intentionally decentralized tool that has no concept of collaboration.

Think about what GitHub actually adds. Pull requests. Code review. Issues. Permissions and access control. Organizations and teams. A canonical “main” everyone agrees on. None of these concepts exist in Git. Git has no notion of a pull request, no owner, no review, no central truth. GitHub invented every one of those on top, because they’re what collaborating humans in a company need, and they’re exactly the things Git deliberately left out.

That’s why certain things never quite arrive, no matter how much engineering GitHub pours in:

• Real-time collaboration stays out of reach. Git is snapshot-and-commit at the bottom: you work privately, then publish a batch. In Git’s model, two people editing the same file at the same moment register as a conflict to resolve later. Git has no way to represent that as a live state two people share right now. You can’t graft Google-Docs liveness onto a substrate whose atomic unit is the after-the-fact commit. The data model forbids it.
• Scale is a permanent fight. Every few years there’s a new mechanism to make Git survive a big repo: LFS, shallow clones, partial clone, sparse checkout, Scalar, VFS for Git. Each one patches over the same root fact: Git wants every client to hold the whole history, and that assumption breaks at scale. These are a recurring tax on a model that didn’t plan for this.
• The owner-less core fights the owner-ful product. GitHub spends enormous effort reintroducing the central authority that Git spent enormous effort eliminating. The two pull in opposite directions, and that tension drives a surprising amount of the platform’s complexity.

GitHub hasn’t run into a ceiling for lack of talent or money. It has run into the ceiling of its foundation. You can build a beautiful house on a foundation poured for a different building, and you’ll spend forever fighting the walls that won’t go where you need them.

The point isn’t that Git is bad

Git is superb. So is the eighteen-wheeler. The claim here is narrower and more useful than “these tools are bad.” A tool inherits the shape of the problem it was born from, and when your problem has a different shape, that inheritance becomes a tax you pay forever without noticing.

For a software company with a single owner, a trusted team, an always-on server, and a desire to collaborate continuously instead of in batches, almost everything that makes Git Git works against you. You don’t get distributed-trust, offline-first, owner-less version control as a feature. You get it as a constraint, and then you layer tools like GitHub on top to claw back the centralized, real-time, single-owner workflow you wanted in the first place.

So here is the question we think is worth answering. What does version control look like when you design it for the problem most teams actually have, instead of inheriting one built for the Linux kernel? That’s what we’re building Fabric to answer: edit like Docs, version like Git, without paying for assumptions that were never yours to begin with.