Why Git doesn't work for AI

Git was designed by and for Linus managing patches on the Linux kernel. A couple decades later, it has metastasized into the default version control for software, from personal websites to billion-dollar codebases. Only ever increasing in complexity.

checkout switches branches, creates branches, and restores files. reset and revert sound like synonyms but have completely different undo semantics; one rewrites history, the other adds to it, and picking wrong can ruin your afternoon. fetch vs pull confuses everyone forever. The staging area is an implementation detail from the Linux kernel mailing list that got promoted to a first-class concept and now every beginner has to learn what the index is before they can save their work.

Git's mental model takes months to internalize. Detached HEAD. Rebase vs merge. Reflog. The difference between --mixed, --soft, and --hard. None of this has anything to do with the actual work. It's all incidental complexity from a tool that was never designed for the job it ended up doing.

Its commit message is a sticky note attached to a diff, written in a hurry, forgotten by Thursday. Six months later you're doing git blame trying to reconstruct the reasoning behind a decision, and the most recent commit says fix stuff. The diff tells you lines 42–67 changed. It doesn't tell you what was tried first, what constraints you were under, or why you picked this approach over three others.

That translation cost — intent to diff, then diff back to intent when something breaks — is where most engineering knowledge goes to die. The source of truth in git is the sequence of states. The reasoning that produced those states is a second-class citizen hanging off the side.

Turns out git is as hard for AIs as it is for humans and for exactly the same reasons. Wrong branch, forgot to stage, detached HEAD, force push gone wrong... Unnecessary conceptual complexity doesn't get easier when you're a language model. Time to start over from scratch.

Starting over: why, not the what

Git records the what and attaches a why. When recording the history of development, why is the interesting artifact while what is derived. Same relationship source code has to a compiled binary — the source is truth, the binary is derived. Let's record the why and attach the what.

Every snapshot in ito is a moment:

moment = {
  why:    "rate limiting to prevent abuse",
  tree:   <sha256 of directory snapshot>,
  when:   2026-03-10T17:12:00Z,
  who:    dhm,
  parent: <sha256 of previous moment>
}

Four object types: blob (file content), tree (directory snapshot), moment (snapshot with intent), thread (named pointer to the latest moment). No index. No staging area. No pack files. No gc. No detached HEAD state.

Storage is content-addressed under .ito/objects/. Objects are immutable. Nothing is ever overwritten. Sync is safe by construction because rsync can only add objects, never corrupt them.

Track only what matters

The git question "how did we end up with 10GB of build output" in version control and 200 line .gitignore files are not a thing. ito init creates a .ito/track file. You list what to snapshot:

# .ito/track
*.c
*.h
Makefile
*.md

Opt-in, not opt-out. You name the files you care about; everything else is invisible. Binary assets, build artifacts, node_modules — they don't exist as far as ito is concerned.

The commands

Git has over 150 commands. ito has 15.

ito log "added rate limiting to prevent abuse"
ito history
ito changes
ito search "auth bug"
ito undo
ito on experiment
ito compare alice
ito restore 1.0
ito restore a3f912c auth.c
ito release 1.0
ito releases
ito merge alice
ito sync user@host:/repos/project

ito log instead of git add -A && git commit -m. ito on experiment instead of git checkout -b experiment. ito undo instead of figuring out whether you want git reset --hard HEAD~1 or git revert HEAD.

ito changes is an interactive navigator — arrow keys walk backwards through history, each moment showing a side-by-side diff. What git log -p always wanted to be.

Search

ito search "auth" finds every moment where the intent mentions auth. Not by grepping diffs — by searching the why-layer directly. The intent is the index. It composes:

ito search "cache" | toast "summarize the approach taken"
ito history | toast "what was the team focused on last week"

An agent can ask "find everything related to auth performance" and actually get a real answer. With git, you'd be grepping commit messages and hoping someone wrote something useful.

Collaboration

Whether AI pair programmers, agents, or people, each works on their own thread, syncs to a shared server, one person merges working code into main when ready:

ito on alice
ito log "added login form"
ito sync server:/repos/project

# when ready
ito on main
ito merge alice
ito merge bob
ito sync server:/repos/project

ito sync uses rsync. Push all local objects to the remote, pull all remote objects back, reconcile thread pointers. If both sides diverged, the conflict gets stashed under the remote's hostname — ito sync dave@server:/repos/project stashes as dave, so resolution is ito merge dave. Sync refuses to overwrite unsaved changes.

ito merge is whole-file. If only they changed a file, auto-accept. If both sides changed it, show a side-by-side diff: o for ours, t for theirs, s to skip. No <<<<<< HEAD markers. You see two versions, you pick one, or make your own.

Designed for the way most actual projects work: a few people, a shared server, clear ownership of what gets merged and when.

Releases

ito release 1.0 marks the current moment as a named, immutable release. Can't be overwritten. Syncs automatically. Restore from any release unconditionally:

ito restore 1.0              # whole tree from release
ito restore a3f912c          # whole tree from any moment
ito restore a3f912c auth.c   # single file

Hotfix flow:

ito on 1.0
ito on 1.0-hotfix
ito log "fixed critical bug"
ito release 1.0.1
ito on main

Implementation

Single C file, ~1,100 lines. No dependencies beyond rsync and diff.

We built ito using ito from the first commit. Agents search by intent, not by diffing. One command to save, one to go back. Nothing to reconstruct at the start of a session. Run ito history on the source and you can read the story we wove during development — what we tried, what we changed, what we backed out and why.

ito is part of LinuxToaster — Unix re-imagined for the era of AI.