Minga: version control without an owner — built for AI agents, it signs every commit, understands the code and remembers your whole machine

Every time someone saves a change to a program, they save it in a version control system: the time machine that remembers what changed, who changed it and when, and that lets you go back. For more than fifteen years that machine has been called git, and the history of almost all the planet's software lives in one place: GitHub, owned by Microsoft since 2018. This article tells what minga is —the version control someone wrote for tawasuyu, and today its primary repository—; what it does that git does not —starting with something git never imagined: many AI agents working on the same history—, and what happened in late October, when it stopped storing only code and started storing the whole machine. With the numbers in plain sight, including the ones that did not go well.

The name

In the Andes, the minka —minga, across much of the continent— is collective work: the community gathers to raise a house, an irrigation channel or a harvest, and what gets done belongs to everyone and to no one in particular. It is a tribute to that way of working, not a flag: the project does not speak for any people, it learns from them. And it describes well what this program wants to be: a history raised by many hands —some human and some not—, with no master keeping it.

What git does very well, and what is not its job

It has to be said without caricature: git is a masterpiece. It is fast, it is distributed by design —every copy holds the whole history— and its model of objects addressed by their own hash is so good that minga does the same. It won because it deserved to.

But it has limits that are not defects but decisions from 2005, when nobody imagined that half the changes would be written by a machine:

• It assumes one person in front of their copy. Twelve agents on the same repository step on each other's files, grab each other's index, and only find out they touched the same function when the merge fails.
• It does not know who wrote what. The author of a git commit is a name and an email anyone can type. Signing exists, but it is optional, configured separately, and most people do not do it. In practice, "who did it" is vouched for by the account on the server.
• It does not know what a function is. To git a program is a pile of lines of text. If you move a function from one file to another, git sees one file that lost forty lines and another that gained them; and to merge two branches it compares lines, not syntax.
• Distributed in theory, centralized in practice. git needs no server, but teams coordinate on one, and review, continuous integration, permissions, issues and notifications live there. Leaving GitHub is possible; leaving without losing anything is not.

Minga in front, git behind

In tawasuyu the relationship has already flipped. minga is the primary repository and git is its mirror: every work session commits in minga, on its own branch; minga does the merging, and from there the result travels to git. Building the git tree of a minga commit takes between 0.08 and 0.42 seconds —it reuses everything that did not change—, against 23.7 for the path that rebuilt the whole tree.

Git stays in front only toward the outside: whoever comes from elsewhere clones and pushes with git, because that is what they have installed. And even that is handled by minga: since October 22, git.tawasuyu.net is not a gitea but minga's host, which speaks git at the door and keeps minga inside.

Built for working with AI agents

Much of tawasuyu is written with AI assistants working in parallel —on a single machine there were days with up to eighteen sessions at once—, and minga grew for that. It is the first difference from git, and the biggest:

• Each agent on its own branch, over the same repository. minga commit --branch commits without moving anyone's pointer, a service (minga host) is the store's only owner and serves every session through a socket, and joining two agents' work is not "last one wins": it is a three-way merge of the tree. Measured: without the service, two simultaneous commits left one on the floor; with it, both get in.
• The clash is flagged before the commit. Since the service sees every session on the machine, it knows which functions each one has touched without committing, and minga status warns: "another working tree is also changing this function". In git you find that out at merge time.
• Ask without cloning, over MCP. The host speaks MCP, the protocol assistants use to call tools: an agent asks who calls a function, looks up definitions by name, or requests "the slice" of a task —the files and definitions it touches— without downloading the repository. And a lazy clone brings the commits and leaves the files at the origin until someone reads them: a session does not load 4 GB to touch one.
• The help is signed. Every commit declares which model it was made with (Assisted-by:), signed along with the rest, and can carry its intent —fix, refactor, API break— as its own field inside the signature. Whoever reads the history knows what a person wrote and what a machine did, and what for.
• The memory of why. minga why takes a function and returns, version by version and across renames, the commit that changed it with its whole message, its intent, who helped, the signed reviews, and the forge conversation about that change. It is the context an agent needs before touching something it did not write.
• Tasks with an owner and a yardstick. An agent takes a task with its key for a deadline, and its own push closes it, not someone else's. A task with a yardstick —the test that says whether it is done— counts as closed only when M trusted keys have signed that test green, and the closing commit cannot reach outside the files the task declared it would touch.
• Delegated keys, not passwords. An agent signs with a key its owner delegates to it, with a scope and an expiry; the host tells whose each agent is and until when it may write.
• AI helps where it is useful, and gets checked. A commit message is suggested from what changed per definition, and a merge that clashes can be resolved by a model —but what it proposes is validated again, and a garbage answer is rejected—. What comes out clean without AI never calls it.

It understands the code, not the lines

minga parses the code (Rust, Python, JavaScript, TypeScript, Go and C) and stores, alongside every commit, which functions and types were born, changed or died. Every definition has an identity that does not depend on its name: funny_add and amusing_add with the same body give the same fingerprint, in four languages. That answers questions git cannot:

• minga impact: who calls this function, by resolved symbol and not by text —a comment that names it is not a caller—.
• minga blame and minga log-def: who owns each definition and its whole history, even if it changed name or file.
• minga api-check: whether a change breaks the public API, decided by the signature of what is public and not by a convention.
• minga graft: bring one function from another branch, not a whole commit.
• minga grep: search by meaning —"decide whose turn it is to compile"— and not by word, also across history, saying when what it found existed.
• minga query: history as a database. A small Datalog over commits, authors, definitions, signatures and calls: "which public functions were changed by someone without a signed review", in one line.

Merging by reading the syntax

When two branches touch the same file, git compares lines. minga merges the syntax tree: two changes to different functions in the same file do not clash, a function moved elsewhere and edited on the other side is not duplicated, and the merged file comes out with its formatting and comments, not reprinted. When there is a clash, the conflict is not a broken file with markers: it is a value stored inside the tree, it can be committed, rebased and resolved later, and only the statement that clashed carries markers.

Measured on the real repository: out of 1,059 three-way merges taken from its own history, 982 come out clean, and only one duplicated anything. And it is compared against mergiraf, the reference structural merge tool, as a parity oracle.

Trust without a central authority

In git, whom to trust is decided by the server. In minga each person decides, and it is signed:

• Every commit is signed with the repository's identity (Ed25519), and a commit can carry K signatures from a community, with a threshold.
• Reviews are signatures with an M-of-N quorum, and their consensus is not a count: a lukewarm approval weighs less than a convinced one, and a rejection from someone with high reputation is not diluted. Each person declares whom they trust and how much, and can require more signatures from a change depending on how much code it touches.
• Keys are revoked and rotated by a quorum of guardians, and that revocation travels over the network like anything else.
• A piece of the repository can be encrypted to certain keys: it travels, is verified and merges like any other, but only its recipients can read it.
• The door has a doorkeeper: a node opens to everyone, only to trusted peers for writing, or only to trusted peers for everything.

The entire forge, with no server

What makes GitHub hard to leave is not git: it is everything around it. In minga each piece is a signed record that travels with the history through the same sync session:

• Integration proposals with a quorum, revalidated against today's tip when the target branch moves (minga revalidate): each one ends up integrated, clean, verified, breaking the test, or clashing, and the verdict is signed.
• Comments anchored to a function, not to a line: if the function moves to another file, the comment moves with it.
• Issues, releases with their changelog taken from the per-definition change, state events, and a wiki versioned in the same repository.
• Signed continuous integration: each machine signs "I built this commit, it came out green, the binary has this hash", and with M machines the commit is certified. From there come a bisect that reruns nothing, merges judged by a test before they get in, a cache of reproducible builds, and the grant with which arje, tawasuyu's init, lets a binary boot.

The host: a forge for agents, with git as the door

For the world that uses git, minga has a host: minga-serve. Since October 22 it serves git.tawasuyu.net and git.gioser.net in place of gitea, with the 55 repositories moved and a way back prepared. At the door it speaks git —anyone clones and pushes with what they have installed—, and inside, everything above: protected branches do not ask "did the server's CI pass" but for M signed attestations; agents come in with their delegated keys; the API and MCP answer without cloning; and a web face with no JavaScript, in Spanish, English and Quechua, shows the tasks, the proposals with their per-definition change, the attestations and the provenance of every commit.

Day to day

• No staging area. The working tree is the commit in progress; there is no git add.
• Undo everything. Every operation —commit, merge, rebase, deleting a branch— goes into a journal, and minga undo reverts it; you can also look at the repository as it was after any operation, without touching anything.
• Fast without asking. A filesystem watcher tells the service what changed, and a file that did not change is neither read nor parsed again.
• A commit as a folder. minga mount mounts the tree of any commit as a directory, without checking it out.
• Live editing between two machines. Two people editing the same file at once, each on their own computer, converge to the same content —measured between a laptop and a server: the same md5 on both sides— and what converged enters the signed history.

Taking the load: the numbers

A version control system is judged on the big repository, not on the toy one. tawasuyu's has more than 9,000 commits and about 4 GB of history, and minga has carried all of it since September. Three measurements of how it got there:

And the third is the one that cost the most: between September and October the database that stored the objects broke twice when the disk filled up in the middle of a write, and the second time the recovery deleted everything written after the error. It was replaced entirely. Objects and commits now live in append-only packs, with a checksum per record, a minga fsck the service itself runs every 24 hours, and a live replica of what git cannot rebuild. The mirror went from 9.4 to 4.0 GB. On a bench of 200,000 commits, listing branches went from 1,128 to 9 milliseconds.

Late October: from storing code to storing the machine

Documents already lived in minga: in pluma, the suite's editor, every paragraph keeps its identity across versions, and there is per-paragraph blame, edit proposals, machine-to-machine sync and merging of two versions paragraph by paragraph. The project's plan has a line called, without modesty, minga as the substrate of the whole suite: that the same signed store keep everything a person wants to be able to remember and undo. In late October it was closed. Six new pieces, all working:

And the machine's timeline also reads takana's: the journal where the system records every file that changes, and the generations of every upgrade, appear interleaved with the snapshots of your configuration, and "going back" on an upgrade asks takana for the rollback, since takana is the one that knows how. Tested against a production machine running takana: the 9,299-line journal and its 17 generations fit in 100 entries, and the September 16 upgrade shows up as one entry of 777 files —the same number of changes its generation's manifest records—.

What went wrong, told

A project that only shows what worked is hiding something. Four stumbles from those days, and what each one taught:

• A mirror broken silently for five days. While checking something else a warning showed up: minga's mirror of the takana repository, on the server, had not opened since October 24. The error was only seen by whoever pushed, and whoever pushed every hour was a build farm with nobody watching. It was rebuilt from git in 40 seconds —from 1.8 GB down to 238 MB— and the other three mirrors still on the old database were migrated with their history intact. Making the mirror's error reach somewhere someone reads is pending work.
• A derivation that erased the CI. The first version kept one attestation per machine and per commit, without looking at what had been run. A machine that ran the tests and then a recipe over the same commit overwrote itself: the scientific result, in green, erased the tests' verdict, in red.
• And the fix broke something else. To let them coexist, the tool went into the key of every attestation. That made revalidating a proposal leave two signatures from the same machine where the new one had to replace the old. The derivation test did not catch it: the full suite did, run hours later for a different reason. Now only derivations and checks coexist; everything else, one per machine, as before.
• A test that passed without having tested anything. The operating system's first self-test returned the tree's correct fingerprint, and had saved nothing: it ran before the disk was mounted, and the store function returns the fingerprint even when it does not write. That is why the line it prints now also says whether it could read it back.

What is not there yet

• Toward the outside, the face is still git. Inside, minga is the primary, but whoever comes from elsewhere still clones and pushes with git, and the mirror's trip to origin still goes through git. Two strangers collaborating directly over minga is the step still missing.
• Habit is measured. The pieces for each agent to work on its own minga branch existed since September; measured on October 1, out of 129 commits in 48 hours, only 2 had been born in minga. Since that day every session is born in its own working tree, and the agent path publishes through minga.
• The operating system read minga in a virtual machine, not on hardware. The test boots twice over the same virtual disk; seeing it on a real computer is still missing.
• takana's index does not know about hardware classes yet. The kernel quorum works in the trial-and-promote cycle; recording in the signed index which hardware each package was certified for changes a signed format, and that is why it is takana's decision.
• What is fetched from the network is not kept. Asking another node for a single file downloads it every time; takana keeps its packages on its side, but minga does not remember what it fetched.
• Structural merging has a ceiling in the grammar. Out of 1,059 real merges, 77 end in conflict —some are real clashes, others are what the parser cannot join yet—, and 16 files remain that the parser does not understand, all third-party C.

How to see it

minga lives in the root region of the tawasuyu repository —git.tawasuyu.net, served by minga itself— under 03_ukupacha/minga. The plan, PLAN-VCS.md, tells every phase with its measurements and dates; the work lines are in 03_ukupacha/minga/lineas/, each with what was certified and what is missing, just as it came out; and FLUJO-AGENTE.md tells how an agent works with minga in front and git behind.