Compare
Nexa vs Git
Nexa is the version control protocol Rinko Hub is built on. It keeps Git's two best ideas — content addressing, and trees as immutable snapshots — and reconsiders the rest for how software is built now: several people and several AI agents working on the same code at once, and projects that mix public and restricted files.
The single deepest change
Git treats parallel work as a problem to be resolved: two people edit the same file, one of them wins, and the merge discards the loser. Nexa treats parallel work as the normal condition, and alternatives as data worth keeping. Three agents attempt the same task; the result is three peer candidates that can be compared, combined, or selected between. Selecting one does not delete the others. That is not a user-interface preference — it changes the object model, the reference model, the conflict model and the synchronisation model, which is why everything below follows from it.
Side by side
| Git | Nexa | |
|---|---|---|
| What a branch is | A pointer to one commit. Two people advancing it produce a conflict; a merge picks a winner and the branch that lost is usually deleted. | A named context holding a set of competing candidates. Several versions can coexist; selecting one supersedes the others without deleting them. |
| Recording work | Stage changes into an index, then commit the staged delta. | No staging area. `nexa record` records the working tree; a version is a whole tree, not a delta. Name paths to record a subset. |
| Parallel attempts at the same task | One branch per attempt, and a merge that resolves by choosing. The losing side is discarded. | One workspace per problem, one candidate per attempt. Reconciliation keeps both as candidates; the choice is explicit and the alternative remains, permanently. |
| Synchronising with a remote | Push and pull. A reference has one tip, so advancing it is either a fast-forward or a rejection. | One reconciliation, always symmetric: peers exchange the objects each lacks and converge on the union of candidates. `fetch`, `push` and `pull` are vocabulary over that one engine. |
| Privacy inside a repository | Per repository. A file is as visible as the repository it is in; hiding it from a UI is not security. | Per path. A path assigned to a label is encrypted under that label’s key. A peer without the key stores, forwards and verifies the sealed bytes but cannot read them — or even learn the file’s name. |
| Merging | Line-oriented three-way merge on text; conflicts are marked inside files. | Three-way merge on the object tree, with conflicts reported by path and object identity. Sealed conflicts are identified by label and object id — contents are never decrypted just to compare them. |
| Transport | HTTPS or SSH to a server; the server decides who may read. | A remote is an address and a device identity; every session is a mutual, authenticated, encrypted handshake. There is no plaintext mode and no “trust whatever answers”. |
| AI agents | A token with repository access, indistinguishable from a person once it commits. | Works through the same CLI as a person, in its own workspace, so its versions arrive as candidates for a person to review and select. Agent-specific identities and scoped capabilities are planned, not yet available. |
Two agents, two attempts, one decision
This is the workflow the candidate model exists for. A branch — say platform — holds
a workspace per problem. Ask two agents to implement authentication and each works in its own workspace,
recording versions as it goes — as candidates, so neither attempt displaces the other. When both are
done, the candidates sit side by side. Compare them, merge the better parts into a third version,
or select one — and the other stays in the history as a record of the road not taken, rather than
a deleted branch nobody can find later.
The same mechanism serves two people. Concurrency is the normal case, not the exception handled by merge: at the object level two parties creating identical content produce the same object and different content produces different objects, so nothing can conflict; at the reference level divergence produces an extra candidate rather than an error; only a genuine semantic conflict — the same region of the same file changed two ways — needs a person, and even then both versions persist.
Privacy per file, not per repository
A repository declares which paths are protected in a tracked .nexapolicy file that binds
paths to labels. A labelled path is encrypted under that label's key; an unlabelled path is stored
in the clear. The policy file names labels but never carries keys, so editing it grants nothing —
a contributor may declare whatever they like and gain no access, which is what makes it safe to review
in the open. A contributor entitled to some paths and not others works normally: content they cannot
open is never written to their working tree, and their versions preserve it by reference, byte for
byte. Rinko Hub shows sealed content as sealed — it never learns the name inside the ciphertext, so
it cannot show it.
The commands you already know
| Git | Nexa |
|---|---|
git init | nexa init |
git status | nexa status |
git add … && git commit -m "…" | nexa record -m "…" |
git log | nexa history |
git diff <a> <b> | nexa compare <a> <b> |
git checkout -- <paths> | nexa restore <paths> |
git branch / git switch | nexa branch list / create / switch |
git merge <branch> | nexa merge <branch> |
git fetch / push / pull | nexa sync — or nexa fetch / push / pull |
git clone <url> | nexa get <owner>/<repo> |
Comparison in nexa status is by content, never by timestamp, so a build that rewrites
files unchanged does not leave the tree dirty. A file sealed under a label you hold no key for is
reported as state unknown rather than clean — a reader that cannot see the content is not entitled
to say it is unchanged.
What Nexa does not do
- Import from Git.
import gitis not implemented: it needs rename detection and line-level merge, both deliberately deferred. - Rewrite history. There is no
rebase,stash,reset,blameorclean. Objects are immutable and history is append-only; correction means adding a version, never modifying one. - Advance a remote's selection on push. A push lands a candidate on the remote even for a clean fast-forward; someone still selects or merges it there. This is a consequence of an open design question, not an accident, and it is documented as such.
- Prove who wrote a version. The author of a version is a recorded claim; the device key authenticates transport, not authorship, and the two are deliberately separate.
- Pretend to be Git. No Git object compatibility is claimed or intended. Where a Git word survives scrutiny it is used; where it does not — “branch”, “commit” — a different word marks a genuinely different concept.
See the vocabulary in one place
Candidates, workspaces, labels, sealed content and reconciliation, each in a few sentences.