2026: The First VCS I Actually Chose
Looking back, I never really chose a version control system (VCS). I used whatever the company I worked for had picked. Most of my earlier workplaces ran Subversion on an in-house server. Then in 2011 I joined a company that had adopted GitHub, which meant every engineer was expected to use Git. That’s when I started using Git and GitHub for real.
Coming from Subversion, Git felt unintuitive and hard to use. GitHub also brought a new expectation: clean up your history so it’s easy to review. The commands for doing that were inconsistent and hard to remember, and each one carried the kind of pressure where you can’t afford to slip.
Over time I went numb to it and accepted that this was just how things were. I still couldn’t remember the commands, though. Anything slightly complicated meant a trip to Google, and I steered clear of anything that might cause a conflict. Five years went by that way, then ten. Just as it looked like fifteen would pass the same way, everything changed. AI coding agents like Claude Code arrived, and almost before I knew it, AI was writing more code than humans were. A few years earlier I wouldn’t have believed it.
Give an AI instructions and it writes the code in no time. With everything moving that much faster, Git’s friction-heavy add-then-commit ritual became a real bottleneck. If it worked, I’d commit it for the time being, even if I didn’t yet understand it as thoroughly as code I’d written myself. Then, inevitably, I’d want to change things later. I’d lose important changes somewhere in rebase hell, or give up and pile quick-fix commits on top until the history was a mess. This became an everyday thing.
That’s when I found Jujutsu. In Japan, a wave of introductory articles made the rounds around January 2026, and ordinary developers started to notice it. After reading a few, I figured it would pair well with AI coding and tried it on a project I was working on. Its design philosophy and commands are so different from Git’s that at first I struggled to use it. What kept me from giving up was how much simpler things felt without a staging area, and the comfort of knowing any operation could be undone. After about a month, I could use it reasonably well.
Since then I’ve managed every repository with Jujutsu, and I do all my writing in it too, from blog posts and docs to book manuscripts (this post included, of course). Now that I think about it, moving from Git to Jujutsu was the first time I’d ever chosen a VCS myself. And somewhere along the way, I realized I couldn’t go back to Git. Here are the reasons, as I see them, that I have no desire to go back.
Reason 1: I Never Have to Wonder Whether My Work Is Saved
Git uses a three-state model: working tree → index → local repository. To record a change in history, you first stage it with git add, then run git commit. In Jujutsu, the state of your working copy is itself a commit. From Jujutsu’s point of view, there’s no gap between your working directory and the current commit. Which comes with a few practical upsides:
- You never have to decide when to save to history
- You don’t need anything like
git stashwhen switching tasks - You’re very unlikely to lose work in progress
Keeping track of which files are unstaged or haven’t made it into a commit yet is cognitive overhead that has nothing to do with the actual development work. So is pushing and popping stashes when something unexpected interrupts you. Jujutsu brings those costs close to zero.
For AI coding, with the right configuration, all you have to do is ask an agent to “build feature X.” The work lands in a single commit as it happens, and the agent finishes it off with a message like “feat: X”. In the normal flow, you don’t do any history bookkeeping at all.
You also almost never hit the accident where git reset, git clean, or a shell command deletes files you can’t get back. I’ve had an AI agent delete files I couldn’t recover, and even now, when models are supposedly far better than they used to be, I still see reports of it now and then. Jujutsu commits the working copy as you go1, so in most cases anything deleted by mistake can be recovered from history.
If I were forced back to Git, I’d have to start thinking about saving again, and I’d always be one bad command away from losing work in progress. Just picturing it wears me out. Jujutsu lowers the cognitive load of version control and gives me peace of mind.
Reason 2: Experimenting Is Far Cheaper
Now that an AI agent can build whatever I ask for in moments, I do a lot more trial and error: build something, keep it if it’s good, throw it away and try again if it isn’t. Doing that in Git gets awkward fast. If you experiment in the working tree without committing, you’re stuck when you throw something away and then decide you wanted it after all. If you want it saved, you need branches, and creating, switching, merging and deleting them is enough of a chore that the whole thing suddenly feels heavy.
So how does Jujutsu handle it? The basic unit of history in Jujutsu, roughly equivalent to a Git commit, is the change. When Jujutsu detects edits in the working copy, it updates the current change automatically and keeps the earlier versions too. You just experiment inside a change. Create a new one with jj new and try whatever you want. If you like the result, give it a description (roughly, a commit message). If you don’t, drop it with jj abandon. If you later want it back, jj operation revert <operation ID> undoes the deletion2, and if you only just deleted it, a single jj undo brings it back.
Jujutsu also lets you branch off history at any point without naming anything. Just pass the parent change’s ID to jj new. To compare different approaches to the same task, create several of these sibling changes and move between them with jj edit <change ID>. Give the one you want to keep a description, and jj abandon the rest. That’s it.
Because the change, Jujutsu’s basic unit of history, doubles as a sandbox, experimenting is just part of normal workflow. No merge needed. And since you can’t tell whether an experiment will pan out when you start it, you don’t have to name it up front either.
If I were forced back to Git, I’d definitely be more reluctant to experiment. I can already see myself skipping the branch because it’s a hassle, experimenting in the working tree, throwing something away, wanting it back, and kicking myself.
Reason 3: Rewriting History Is Simple and Intuitive
When I wrote the code myself, I knew it inside out, so my commits were solid and I rarely had to go back to them. But hardly anyone reads every line an AI generates and understands it as well as their own code before committing. So I find myself wanting to change supposedly finished commits far more often than I used to.
Say you want to fold a change to src/styles/global.css into the commit three back. What does that look like in Git, and in Jujutsu? There are two ways to go about it: edit the target commit directly, or make the change on top and squash it into the target commit. Here I’ll compare the first.
Let’s start with Git. You can’t do this with uncommitted changes lying around, so if you have any, you first need to stash them with git stash -u. Then:
git rebase -i HEAD~4
In the editor that opens, change pick to edit on the target commit’s line and save.
- pick bbbbbbb Commit message for B
+ edit bbbbbbb Commit message for B
pick ccccccc Commit message for C
pick ddddddd Commit message for D
pick eeeeeee Commit message for E
Your working tree is now at commit B. Edit src/styles/global.css, then commit it.
git add src/styles/global.css
git commit --amend --no-edit
But you’re not done. The commits after it still need to be replayed on top of that edit. Run git rebase --continue and pray there’s no conflict. If there is, the rebase stops, and you fix the files, git add, and git rebase --continue again, as many times as it takes. If you lose track of what’s going on, git rebase --abort sends you back to square one. It wears you out.
Now the same thing in Jujutsu. jj edit @--- moves the working copy to the change three back. Edit src/styles/global.css. Jujutsu automatically rebases the descendant changes onto it, so if there are no conflicts, you’re done. Even if a conflict comes up, the automatic rebase finishes without stopping. Just jj edit your way to the conflicted change and fix it there, and the automatic rebase runs again.
Fewer steps is a nice bonus, but the bigger win is that it feels far more intuitive. Go to the point in history you care about and edit the files. Jujutsu handles the rebasing on its own, so you barely notice it’s happening. In Git, for some reason, rebase is the star of the show. You start with git rebase and you finish with git rebase. It’s counterintuitive, and the steps in between are fiddly enough that I never did manage to memorize them.
If I were forced back to Git, I’d probably avoid rewriting history whenever I could because of the hassle. Quick-fix commits would pile up, or unrelated changes would get stuffed into whatever commit was handy, and my history would get much harder to read.
Reason 4: I See History as a Graph, Not Just a Timeline
Let’s start by comparing the output of each tool’s log command. The first is git log, the second jj log. By default Jujutsu hides most immutable changes, so I passed -r :: to lift that limit.
Git’s log shows what happened on your current branch, in order, in a straight line like a timeline in a history textbook. Jujutsu’s log gives you a bird’s-eye view of the whole history, draws the branching with ASCII art, and packs in more information. You take in far more at a glance.
What happens when you move to a past point in history is different too. Run git checkout <commit ID> in Git, and git log no longer shows anything after that point. Run jj edit <change ID> in Jujutsu, and the log stays as it was. Only the @ marker, which stands for the working-copy commit, moves to that change’s node.
These differences in how the log looks and behaves say a lot about the two tools’ design philosophies. In Git, you’re generally expected to be on some named branch while you work, and you’re always being pushed to the tip of that one line of history. That may be why the default log doesn’t bother showing where you are in the overall history or what’s happening outside that timeline3.
Jujutsu has nothing that corresponds to Git’s named branches4. You can move freely to any editable node in the history, regardless of which line it sits on. That’s why a graph of the overall history is so useful.
A lot of what makes rewriting history easy in Jujutsu comes down to this dense, readable log. It’s like working in video editing software with a multi-track timeline in front of you. By comparison, editing history in Git feels like cutting analog film with scissors and gluing the pieces back together.
git log can draw an ASCII tree graph too if you pass --graph, though it’s not as readable as Jujutsu’s. But seeing the graph doesn’t let you edit across branches intuitively and safely the way Jujutsu does, so even if I went back to Git, I’d hardly ever use it.
Where Git Fits In Now
It’s been over six months since I switched to Jujutsu completely, but I haven’t actually stopped using Git. Jujutsu’s storage layer is pluggable, and it can use a Git repository as its backend. When you initialize a repository with Jujutsu, by default you get a colocated workspace, with .git/ and .jj/ sitting side by side in the project root. I’m still using a Git repository. I’ve just stopped using Git’s interface to it. The git command still works if you want it.
Because of that compatibility, nobody around you can tell you’re using Jujutsu unless you say so. On a team using GitHub or GitLab, it’s entirely possible someone has been quietly using Jujutsu all along. Day to day, about the only times I think about Git are when I set up a repository with jj git init or jj git clone, and after that when I sync with the remote using jj git fetch and jj git push.
I started using Git because of GitHub, and I switched to Jujutsu when I went all in on AI coding. Now there’s no going back. After years of being trained by Git, some of Jujutsu’s ways felt odd at first. But when you look at the history of version control, it often turns out Git was the odd one, and these days Jujutsu feels more natural to me in most situations.
Jujutsu is still niche, though, and it frustrates me that a tool this good isn’t better known. The catch is that it’s compatible with Git but built on a very different mental model. If you try it with a Git mindset, working from a Git-to-jj command comparison, you’ll barely notice the benefits. So I wrote a beginner-friendly Jujutsu guide designed so you won’t get stuck , one built around switching mental models.
Juju-chu! — Starting Your Jujutsu × AI Workflow with jj new
A hands-on book on adopting Jujutsu (jj) with Claude Code and Codex: automatic snapshots, undoable operations, and safe history rewriting.
juju-chu.com
It’s called Juju-chu! — Starting Your Jujutsu × AI Workflow with jj new, and with its light-novel-style cover it looks pretty playful, but the content is the real deal. It takes Jujutsu beginners step by step to the point where they can use it with confidence. If this post got you curious about Jujutsu, take a look. The page above has a sample you can read right in your browser.
Footnotes
-
To be precise, whenever any
jjcommand runs, Jujutsu checks for differences between the working copy and the latest state in history, and commits them if there are any. AI agents told to use Jujutsu typically check their work withjj statusor a similar command at natural breaks in a task, and that’s when the commit happens. ↩ -
Separately from the regular log, Jujutsu keeps an operation log that records every operation performed on the repository. Each entry has an operation ID, which you can use to reverse that operation or restore the files as they were right after it. ↩
-
This refers to the default behavior. With
--all, you’ll see every branch in your local repository and the commits reachable from them. ↩ -
Jujutsu’s bookmarks are treated as branches when working with Git, but conceptually they’re a different thing. ↩
