Get AI summaries of any video or article — Sign up free
Git is holding us back thumbnail

Git is holding us back

Theo - t3․gg·
6 min read

Based on Theo - t3․gg's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Git’s commit-and-snapshot model is increasingly misaligned with continuous human-and-AI collaboration, where iteration happens in smaller, faster loops than commits assume.

Briefing

Git is still the backbone of modern software collaboration, but the commit-and-branch model is increasingly misaligned with how code gets written today—especially when AI agents and non-expert contributors are part of the workflow. The core claim is that source control has become a bottleneck: developers spend too much mental energy wrestling with merges, rebases, conflicts, and review logistics instead of focusing on building software. As collaboration turns into continuous back-and-forth (humans and agents iterating rapidly), the “snapshot” nature of Git starts to feel like the wrong primitive.

The argument starts with a usability and cognitive-cost critique. Git’s learning curve is steep—rebase and merge strategies aren’t intuitive until long after people begin using the tool—and the system’s failure modes can be brutal. A particularly pointed example is how merge conflicts sit in an awkward layer of Git: during a conflict, committing partial progress isn’t straightforward, which breaks common workflows like partial staging (e.g., using add-p to commit only the parts that are ready). The result is that even when developers know what they want to keep, Git forces them into a binary state: either everything is clean, or the repo is in a conflict/merge state.

That mismatch is traced to Git’s origins. Git emerged from the Linux community’s needs—decentralized contribution, patch submission, and review—at a time when open-source change management was chaotic and often happened via email. GitHub later added a centralized experience through pull requests, comments, and line-level review, which helped Git become the default across workplaces and replaced older systems like SVN and BitKeeper. But the historical fit for email-era collaboration doesn’t automatically translate to today’s development reality, where work is iterative, tool-assisted, and increasingly conversational.

The transcript then pivots to what a replacement would need to fix: Git lacks a “middle layer” between tiny code changes and full commits/pull requests. There’s little native support for reviewable, stackable units that are smaller than a commit but richer than raw diffs—making “PR trains,” stacked pull requests, and branching-off-while-waiting for review painful. Even code review suffers: GitHub’s UI and workflows can force developers to bounce between local tooling and the web interface just to render and comment on large pull requests.

Against that backdrop, Zed IDE’s push for a Git-compatible alternative becomes the centerpiece. Zed, backed by Sequoia with a $32 million Series B, is described as “waging war on Git” by introducing Delta DB (Delta), an operation-based version control concept meant to turn an editor into a collaborative workspace. Instead of tracking only commits and snapshots, Delta DB aims to record operations with edit-level granularity using CRDTs, preserving the dialogue that produces code—human and AI—linked durably to the exact locations in the evolving codebase. The vision is that conversations, prompts, and agent decisions remain navigable and queryable, not scattered across Slack, Discord, or stale commit history.

The transcript also emphasizes execution credibility: Zed is built from scratch in Rust, has an agentic standard (ACP), and reportedly debugged performance issues on the creator’s own MacBook by building custom versions and troubleshooting locally. The takeaway is not that Git is useless, but that the primitives it enforces—commits, snapshots, and merge states—don’t match continuous collaboration. Delta DB is presented as a serious attempt to rebuild version control around the way modern software is actually created and reviewed.

Cornell Notes

Git’s commit-and-snapshot model became the industry standard because it fit email-era collaboration and later GitHub’s pull-request workflow. But modern development now includes AI agents and rapid, continuous iteration, and Git’s primitives force work into discrete commits and painful merge/conflict states. The transcript argues Git lacks a “middle layer” for reviewable, stackable progress between commits and pull requests, which makes PR trains, partial work, and agent back-and-forth harder than they should be. Zed’s Delta DB (Delta) is pitched as an operation-based, Git-interoperable approach using CRDTs to record edits and preserve the dialogue behind code. The goal is a living, navigable history where prompts, decisions, and discussions stay linked to the code as it evolves.

Why does the transcript claim Git becomes a bottleneck when AI agents enter the workflow?

Git is built around discrete commits and snapshots. AI collaboration often looks like rapid back-and-forth—guiding an agent, correcting course, and iterating without waiting for a full “commit-sized” checkpoint. Forcing every interaction into commit-based workflows is compared to having a conversation through a fax machine: context gets fragmented, and the “state” that matters (what the agent changed, why, and what was tried next) lives in editor caches or chat history rather than durable source control artifacts. The transcript argues that this breaks the link between conversation and the exact code locations being discussed.

What specific Git pain point is highlighted around merge conflicts and partial progress?

Merge conflicts are described as sitting in an awkward layer of Git where developers can’t easily commit partial work. A common workflow—partial commits using add-p (staging only selected hunks)—works until a merge conflict appears. During that conflict window, committing the “right” parts while ignoring or stashing the “wrong” parts isn’t straightforward because Git expects either a clean state or a merge-conflict state, not “commit while resolving.” The transcript also notes that many AI tools handle only part of a conflict correctly, but the developer still can’t safely commit the partial solution.

How does the transcript explain Git’s historical fit—and why that fit may no longer match today?

Git’s origins are tied to Linus Torvalds and the Linux community’s contribution model: decentralized access, patch submission (often via email), and review/merge by maintainers. That environment rewarded a system that could represent changes as well-formatted history for approval. GitHub later added a centralized developer experience through pull requests and line-level comments, helping Git dominate workplaces. The transcript’s critique is that these primitives were optimized for that earlier collaboration pattern, not for continuous, tool-mediated dialogue.

What does “missing middle layer” mean in the context of commits and pull requests?

The transcript frames a spectrum of granularity: from a single line of code up to the whole repository. Git natively tracks commits (small) and pull requests (larger), but leaves a gap in between—work that is ready for review but not yet ready for merge, and work that can be stacked without breaking history. It also claims that before a commit, changes are largely untracked unless developers commit frequently, which disrupts workflows. This gap makes stacked PRs, PR trains, and partial, reviewable progress harder than they should be.

What is Delta DB (Delta) supposed to change compared with Git?

Delta DB is presented as operation-based version control that records incremental changes as they happen, rather than only storing snapshots at commit boundaries. It uses CRDTs to synchronize changes and is designed to interoperate with Git. The key promise is that discussions and edits can be anchored to fine-grained locations in the codebase (including “character level permalinks”) and survive code transformations. That would let prompts, agent decisions, and human context remain linked to the evolving code instead of becoming stale snapshots.

Why does the transcript treat Zed’s approach as credible rather than just another “AI hype” pitch?

Credibility is tied to engineering choices and follow-through: Zed is built from scratch in Rust with its own rendering layer, and it reportedly debugged performance issues on the creator’s MacBook by producing custom builds and troubleshooting in person. The transcript also points to Zed’s agentic tooling direction (ACP) and its open-source licensing posture (GPL3 for the codebase and Apache for the framework). The overall message is that the team is willing to do hard, low-level work needed to make a new collaboration/version-control model practical.

Review Questions

  1. What kinds of collaboration context does the transcript argue Git fails to preserve, and where does that context end up instead?
  2. How do merge conflicts interfere with partial commits, and why does that matter more in AI-assisted workflows?
  3. What “middle layer” between commits and pull requests would a better system need to support, according to the transcript?

Key Points

  1. 1

    Git’s commit-and-snapshot model is increasingly misaligned with continuous human-and-AI collaboration, where iteration happens in smaller, faster loops than commits assume.

  2. 2

    Merge conflicts create a workflow dead zone where partial progress can’t be committed cleanly, undermining common practices like partial staging (e.g., add-p).

  3. 3

    Git’s historical design fit email-era patch review and later GitHub’s pull-request UX, but that origin story doesn’t automatically match today’s agent-driven development.

  4. 4

    The transcript argues Git lacks native support for a “middle layer” of reviewable work between commits and pull requests, making PR trains and stacked PRs painful.

  5. 5

    Code review friction is partly blamed on GitHub’s UI and workflow limitations for large PRs, pushing developers toward editor-based review tools.

  6. 6

    Zed’s Delta DB (Delta) is pitched as an operation-based, Git-interoperable alternative using CRDTs to record edits and preserve dialogue linked to code locations over time.

  7. 7

    The transcript frames Zed’s engineering credibility as coming from ground-up Rust work, open-source practices, and hands-on performance debugging.

Highlights

Git’s biggest modern flaw isn’t that it can’t track changes—it’s that its snapshot boundaries don’t match continuous collaboration, especially when AI agents iterate between commits.
Merge conflicts break partial-work workflows: developers can’t easily commit the “right” parts while leaving the conflicting parts unresolved.
Delta DB aims to replace snapshot-centric history with operation-level tracking so prompts and decisions stay durably linked to the code as it evolves.
Zed’s pitch is backed by a ground-up Rust editor and reported hands-on performance debugging on a MacBook, not just a conceptual rewrite.

Topics

  • Git Limitations
  • Operation-Based Version Control
  • CRDTs
  • AI Agents
  • Code Review Workflows

Mentioned

Get summaries like this for any content

Videos, articles, research papers — all summarized by AI and searchable in one place.

Start building your library