The Interface Problem: Seventeen Million Dollars and a New Face

The Man Who Already Did This Once

This is episode three of Git Good, Season Two.

Scott Chacon co-founded GitHub. He wrote the book on Git. Not a book. The book. Pro Git has been downloaded millions of times and translated into dozens of languages. If you have ever searched for how Git works and landed on something that actually made sense, there is a good chance Chacon wrote it. He understood Git better than almost anyone alive, and he used that understanding to build the platform that put a friendly face on it. GitHub took a tool that communicated in plumbing commands and gave the world pull requests, fork buttons, and a green contribution graph. Chacon helped build the face that made Git usable for millions.

He left GitHub in two thousand sixteen. He started a language learning company called Chatterbug, learned German, married a German woman, and for seven years did not think much about version control. Then he came back.

In April two thousand twenty-six, Chacon's new company GitButler announced a seventeen million dollar Series A led by Andreessen Horowitz. The pitch was simple and audacious. Git's interface is broken. Not just the error messages, not just the vocabulary, but the entire model of how humans interact with their code history. And this time, Chacon is not building a website on top of Git. He is trying to replace the way developers think about changes entirely.

We are not building some better Git. We are building the infrastructure for how software gets built next.

The last two episodes described the wall. The hostile error messages. The detached HEAD panic. The five commands people memorize without understanding. This episode is about the people who decided to tear the wall down. And the question underneath all of their work: is the hostility a bug that can be fixed, or a feature that is holding the whole thing together?

A Thousand Frustrations

To understand why Chacon came back to version control, you have to understand what bothers him about the tool he once evangelized. In interviews, he does not mince words. There are, he says, a thousand things that are really frustrating about Git. But his frustration is specific. Git can only hold one context at a time.

You are working on a feature. A bug report comes in. To look at it, you have to stash your current work, or commit something half-finished, or create a temporary branch. Then you fix the bug, switch back, pop your stash, hope nothing conflicted, and resume. Every developer has done this a million times. It feels like an immutable law of version control, as natural as gravity. Chacon's argument is that it is not a law at all. It is an accident of implementation.

On a podcast, Chacon put it bluntly: there is no particular reason it has to be like this. It is only because of the design of the index and the HEAD.

The index. The staging area. The invisible middleman between your files and your commits that Season One covered as part of Git's elegant plumbing. That same plumbing now looks different when you are trying to juggle three things at once and Git insists you can only hold one. The elegance, Chacon realized, had calcified into a constraint. Developers were not choosing to work on one thing at a time. They were being forced to, by a design decision made twenty years ago for a mailing list workflow that almost nobody uses anymore.

So GitButler introduced virtual branches. Instead of Git's model where the entire working directory belongs to one branch, GitButler lets you assign individual file changes to different branches simultaneously. You are fixing a typo in the readme, refactoring a utility function, and adding a new feature. Three branches, one working directory, no stashing, no switching. Each change knows where it belongs. When you are ready, you push them independently.

It is a deceptively simple idea that requires rethinking everything about how a Git client works. GitButler does not just display what Git is doing. It maintains its own model of what you are doing, translates your intentions into Git operations, and presents a view of your work that Git itself cannot produce. The virtual branch is not a Git concept. It is a GitButler concept built on top of Git's storage.

The Other Road

Seven thousand kilometers from Chacon's office, a Google engineer named Martin von Zweigbergk was solving the same problem from the opposite direction.

Von Zweigbergk had previously worked on Mercurial. That name should ring a bell. In the format wars of the late two thousands, Mercurial was Git's most capable rival, a distributed version control system that did almost everything Git did but with a friendlier interface and clearer mental model. It lost. Not because it was worse, but because GitHub existed and Mercurial's GitHub did not. Network effects are brutal and indifferent to technical merit.

But von Zweigbergk carried Mercurial's lessons with him. In late two thousand nineteen, he started a hobby project. He wanted to know what version control would look like if you started from scratch, kept Git's storage layer for compatibility, but threw away every assumption about how humans should interact with their history. He called it Jujutsu. The command is jj. And the first thing it does is kill the staging area.

No git add. No index. No invisible middleman deciding what goes into the next commit. In Jujutsu, your working directory is the commit. Every change you make is automatically part of a commit that is being continuously updated. When you want to start something new, you type jj new. That is it. The old commit is done. You are now working on a fresh one. There is no liminal state between "changed a file" and "committed the change." The two are the same thing.

This sounds radical until you think about what the staging area actually does. It lets you commit only some of your changes. A useful feature, certainly. But Jujutsu handles that differently. If you decide after the fact that a commit contains too much, you split it. If two commits should be one, you squash them. The difference is philosophical. Git asks you to plan before you commit. Jujutsu lets you commit first and organize later.

Undo Everything

But the staging area is just the opening move. Jujutsu's deeper innovation is its operation log. Every single thing you do in Jujutsu, every commit, every rebase, every merge, every branch move, is recorded in a sequential log. And every single one of those operations can be undone with a single command.

Think about what that means for the wall from episode one. Half of the panic in Git comes from the fear that you have done something irreversible. You rebased when you should have merged. You amended a commit that was already pushed. You resolved a merge conflict wrong and now the code is broken and you do not know how to get back. Git has the reflog, a hidden safety net that most developers do not know exists and fewer know how to use. Jujutsu makes undo a first-class citizen. Not hidden. Not arcane. Just type jj undo.

I am not sure what would make me go back to using Git other than Jujutsu being abandoned entirely.

That is Chris Krycho, a developer who switched to Jujutsu and wrote about the experience after seven months. His review captures something important. Krycho is not a Git novice. He is the kind of developer who understands rebasing and cherry-picking and interactive staging. He switched not because he could not use Git, but because Jujutsu made him realize how much of his Git workflow was compensating for Git's design rather than doing actual work.

Git's internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model.

There is also the conflict model. In Git, a merge conflict is an emergency. Everything stops until you resolve it. You cannot commit, you cannot switch branches, you cannot do anything until every conflict marker is gone. In Jujutsu, conflicts are just data. A conflicted commit exists in your history like any other commit. You can keep working. You can come back to resolve it later. The rebase always succeeds, even if the result has conflicts in it, because Jujutsu records the conflict state rather than refusing to proceed.

As of early two thousand twenty-six, Jujutsu has over twenty-seven thousand stars on GitHub, which is ironic given that it is a tool for people who find Git frustrating. It is written in Rust. It is fast. And it reads and writes Git repositories natively, which means you can use Jujutsu on any project that uses Git without anyone else on the team knowing or caring. Your Jujutsu workflow pushes and pulls from the same remote as everyone else's Git workflow.

Two Philosophies

GitButler and Jujutsu represent two fundamentally different theories about what is wrong with Git.

GitButler says the problem is the client. Git's storage model is fine. The way commits work, the way branches are just pointers, the content-addressed object store, all of that is elegant and proven. What fails is the interface between the human and that model. So GitButler builds a new interface. Virtual branches, drag-and-drop change assignment, real-time conflict detection. It wraps Git in something humane and adds concepts Git does not have, while keeping every commit, every push, every pull request compatible with the Git the rest of the world uses.

Jujutsu says the problem goes deeper. The staging area is not just a bad interface. It is a bad idea. The way Git handles conflicts is not just unfriendly. It is architecturally limiting. The operation model, where some things are undoable and others are not, is not a documentation problem. It is a design problem. So Jujutsu builds a new command layer. Different verbs, different nouns, different mental model. But underneath, it still reads and writes the same Git objects, the same pack files, the same references. Your repository does not change. Your experience of the repository changes completely.

Both keep Git's storage. Neither is trying to replace the engine. They are trying to replace the dashboard, the steering wheel, and the pedals. One puts a touchscreen over the existing controls. The other redesigns the cockpit but keeps the same motor underneath.

Our development practices have been shoehorned into what Git could do for such a long time. It would be amazing to see what we could do with tooling that was actually designed for those practices.

The Wrapper Ecosystem

GitButler and Jujutsu get the headlines, but they are not alone. There is an entire ecosystem of tools built on the premise that Git's command line is the problem and someone else should solve it.

Lazygit is a terminal interface for Git written by Jesse Duffield, released in two thousand eighteen. It has thirty-seven thousand stars on GitHub. Thirty-seven thousand people saying, in effect, I want to use Git but I do not want to type Git commands. Lazygit gives you a keyboard-driven interface that shows your repository state visually, staged files on one side, commits on the other, branches in a panel. You press a key instead of remembering a command. Duffield identified three specific failures in Git's experience: different file states require different commands to undo, there is no universal undo for the working tree, and merge conflicts are not treated as a first-class workflow. Lazygit fixes all three by putting a consistent interaction model over Git's inconsistent one.

Lazygit is not only an amazing tool for everyday use, but also an inspiration around devtools UX. The simplicity, consistency, discoverability, sane defaults, and shortcuts for common flows should be on the radar for anyone who builds devtools.

Then there is Magit, the Emacs package that has been downloaded over three point eight million times. Magit users tend to be the kind of developers who have strong opinions about text editors, but the download numbers are not a joke. Three point eight million people chose to interact with Git through an intermediary rather than directly. The intermediary happens to live inside Emacs, but the principle is the same as Lazygit, the same as GitButler. Git's command line is not the way most people want to work.

There is tig, the ncurses-based Git browser for reading logs and blame output. There are dozens of graphical Git clients, from Sourcetree to Fork to Tower. There is an entire industry of companies whose product is fundamentally "Git, but with a face you can stand to look at."

Every one of these tools exists because Git's own interface was not good enough. That is not a criticism. It is a market signal. Hundreds of developers have independently concluded that the best thing they can build is a translation layer between Git and the humans who use it.

The Agent Problem

There is one more reason Chacon's timing matters, and it is the reason Andreessen Horowitz wrote a seventeen million dollar check. Agents.

The pitch on GitButler's blog post does not just talk about developers. It talks about agents and developers working together. The command line interface that confuses humans is also confusing the AI systems that are increasingly writing, reviewing, and committing code. When an agent needs to switch context, it hits the same stashing problem a human does. When it needs to organize changes across multiple concerns, it faces the same one-branch-at-a-time limitation. Git was designed for humans sending patches over email. Now it needs to work for humans, agents, and combinations of both, all operating on the same repository simultaneously.

As Chacon put it in the funding announcement: developers do not struggle because they cannot write code. They struggle because context falls apart between tools, between people, and now between people and agents.

GitButler's CLI, called But, is designed with this explicitly in mind. It is scriptable, structured for automation, and aware that the thing driving it might not be a person typing commands. It is a Git interface designed for a world where half the commits might come from machines. Jujutsu, by making every operation undoable and eliminating the staging area's complexity, is accidentally well-suited for the same future. An agent that can always undo its last action is a safer agent. A workflow that does not require careful staging before each commit is a workflow an agent can actually follow.

The thesis underneath both tools, and the thesis underneath this episode, is a single sentence: we are all teaching swarms of agents to use a tool built for sending patches over mailing lists. The interface that was designed for kernel developers emailing diffs in two thousand five is now the interface that every AI coding assistant in the world has to navigate. Something has to give.

The Load-Bearing Question

But here is where it gets complicated. The wall from episodes one and two is not just a UX problem. Some of Git's hostility might be structural.

Consider the staging area. Jujutsu eliminates it and the result is, by most accounts, a better experience. But the staging area also forces a moment of intention. Before you commit, you have to decide what goes in. You have to look at your changes and choose. That friction is annoying when you are in a hurry, and it is also the last moment where a human brain is between the code and the history. Remove it, and you remove a speed bump. Speed bumps are annoying. Speed bumps also slow you down before the intersection.

Or consider Git's refusal to proceed during a merge conflict. Jujutsu lets you keep working with conflicts in your history. That is more flexible. It is also a world where conflicting code can exist in your commit log, where a bisect might land on a broken state, where the pressure to resolve conflicts immediately is replaced by the temptation to resolve them later. Later has a way of becoming never.

Git's hostility has a cost. People hit the wall and give up, or they memorize five commands and never go deeper, or they make mistakes they cannot recover from because the error messages do not help. All of this is real and documented. But Git's hostility also encodes a set of assumptions about what careful version control looks like: you should know what you are committing, you should resolve conflicts before moving on, you should understand what a rebase does before you do one. Those assumptions might be wrong. They might also be the reason the Linux kernel's history is pristine after two decades.

The question this episode leaves you with is not whether Git's interface should be improved. It should. The error messages should be clearer, the undo story should be better, the vocabulary should match what users actually think. The question is whether you can fix the interface without changing what the interface enforces. Whether a friendlier Git is still Git in the ways that matter. Whether the wall is cruelty, or curriculum.

The Roads Being Built

The format wars settled a long time ago. Git versus Mercurial versus Darcs versus Bazaar. Mercurial was friendlier. Darcs had a more elegant theory of patches. Bazaar had Canonical behind it. They all lost. Network effects chose Git, and GitHub cemented the choice. The roads not taken.

Martin von Zweigbergk worked on one of those roads. Mercurial. And then he started building a new one. Jujutsu borrows ideas from Mercurial, from Darcs, from the patch-based systems that lost the format wars, and it grafts them onto Git's storage layer. It is not the road not taken. It is the road being built now, and it connects to the highway that already exists.

Scott Chacon built the most important on-ramp to that highway. GitHub did not change Git. It changed what you saw when you arrived. Now he is building a new on-ramp, one that lets you drive differently even though the road underneath is the same. Seventeen million dollars says the bet is worth making.

Between them, these two projects represent the most serious attempt to fix Git's daily experience since Git itself was created. Not by replacing it. Not by forking it. Not by competing with it. By accepting that Git won, that Git's storage is the standard, that every repository in the world speaks Git, and then asking: does the interface have to be this way? Does the wall have to be this tall?

The answer, from twenty-seven thousand stars on one project and seventeen million dollars on another, is no. The answer from thirty-seven thousand Lazygit users and three point eight million Magit downloads and an entire industry of graphical clients is no. The answer from every developer who has ever Googled "how to undo git commit" is no.

Git won. The face it won with is being replaced. And nobody, not even the man who helped build the first one, thinks that is a bad thing.

That was episode three of Git Good, Season Two.

git stash. The command that proves Git can only think about one thing at a time. You are working on something, an interruption arrives, and Git says: put your current work in a pile, switch contexts, deal with the interruption, then come back and hope the pile is still intact. Virtual branches, Jujutsu's always-a-commit model, even Lazygit's visual panels, they all exist because stash is a workaround dressed up as a feature. Next time you type git stash, consider that you are manually doing what your version control tool should handle automatically. Then consider that two well-funded projects agree with you.