Published as written. Dinis Cruz passed it to this site on 28 October 2026; it is not yet in the CLI repository. cli.sgit.ai's build agent checked three of its claims against the PyPI release 0.26.0 on 28 October and found all three hold: sgit write leaves other edits uncommitted, a zip holding a vault key is refused at commit, and a pull refuses a rewound head that the host accepted (the script). The site's summary of it, row by row, is sgit and Git.

Review: "What sgit does that Git does not" (newsroom.sgit.ai, article No. 308, 27 Oct 2026)

Article: https://newsroom.sgit.ai/articles/what-sgit-does-that-git-does-not.html (.md twin read in full). Checked against: this repository at 640069a (branch claude/charming-babbage-5hzcxq, the same code as dev): the source, sgit --help for every command group, CHANGELOG.md, the threat model (team/explorer/appsec/threat-model/v0.21.0__threat-model.md) and the response and release notes under team/humans/dinis_cruz/claude-code-web/10/. Numbers that come from the newsroom's own briefs or from cli.sgit.ai pages are not in this repo. They are marked "external": not contradicted, just not checkable from here.

In one paragraph. The article is accurate on the whole, and its honesty sections are mostly fair. There is one headline number we cannot source: "29 minutes to 4.6 seconds" for a one-file commit on a 76,000-file vault. The "commits signed since 0.19.0" line is wrong the other way: commits were signed long before October, and 0.19.0 added verification. Two claims are too strong, both in sgit's favour:

• "sgit's signatures say which clone wrote a commit" (see TM-R01).
• "every index is verified against a signed commit" (see TM-R42).

The article also undersells sgit. It does not claim we lack shallow clones: it lists them under "Git has it too", which is right. But it says sgit refuses partial commits (sgit write does them), and it puts "read one file with no clone" wholly in the future (it works today on normal vaults). It also leaves out several things Git has no equivalent for, listed in section 2.

Almost everything on the "Git is ahead" list can be built client-side, as Git builds it. The things that cannot be built are the ones that need the host to read content, and one more: taking back data a reader already has.

1. Claim by claim

✓ = matches the code or our records · ✗ = wrong · ~ = right but needs a qualifier · ext = external, not checkable here.

Releases and numbers

What Git has no equivalent for

What Git has too

Where Git is ahead

Next, not now

Housekeeping claims

2. What we have that the article misses or says we lack

Things the article says we lack, or puts in the future:

• Partial commits (row 28): sgit write … --also … --push --json. It commits named files atomically to HEAD and, with --push, publishes them in one call. That is the agent form of git commit <paths>.
• One file with no clone (row 33), on a normal vault: the browser reader does it today (four GETs plus one per folder level), and sgit cache add makes it one batch request. sgit history log --vault-key … already runs with no clone; cat does not yet (section 3).
• Key rotation: sgit vault rekey and sgit vault move (rotation plus an optional move to another server). GitHub has nothing to rotate; a leaked Git deploy key is revoked on the server.
• Search / history tools (row 32): history log --grep --since --until --author --file --patch --stat --json, history diff A..B, history show, history reflog, history undo, history revert, history reset, commit --amend, vault stash, signed vault tag, resolve, merge-abort.
• Shallow and partial clones: clone --depth N, fetch --unshallow, clone --path, fetch <folder> (widen), clone --sparse, clone --no-checkout, clone --bare, clone-branch, clone-headless, clone-range. The article files these under "Git has too", which is fair; we are not behind there.

Things Git has no equivalent for that the article leaves out (candidates for its first list, or for the follow-up article):

1. Custody without access: sgit vault mirror copies a published vault you cannot read, keyless, and verifies it. A backup service or a second host can hold and check the vault and learn nothing.
2. Policy carried by the repository and enforced at clone and pull: the format gate (min_client, features) and signatures-required live in the encrypted branch index, and every sgit client enforces them before writing anything. Git's signature checks are each user's local config; a repository cannot require them of its cloners.
3. Rewind detection on every clone: a remote head that does not descend from the last accepted one is refused by name (pull --accept-rewind to take it). Git's default + refspec takes a forced update with one line of output.
4. A secret guard: commit refuses vault keys, key-bearing zips and in-tree symlinks to secrets (TM-F11, TM-F18, TM-F27).
5. Agent-shaped writes: write --push --json and checkout --since-pull. Two scoped agents can never conflict (already in the article).
6. Serving: sgit serve runs the vault UI and API locally in a container; sgit serve --static and sgit publish lay a vault out for any static host. A read-only clone from a published read key needs no account and no server code.
7. A computable cache: sgit cache add <path> puts a fixed-cost read of a hot file at a location only key holders can compute, for edge functions. Git has no read path that skips the tree walk.

3. What we don't have, and how to build it

Git is a client-side program; almost all of the "Git is ahead" list runs on the client in Git too. Each row below works on plaintext the client already holds, and needs no new server feature unless the row says so.

4. What is impossible, or only partly possible, under zero knowledge

These are limits of the model, not of effort. Each one has a client-side substitute.

1. Anything the host must read to do. Server-side search, diffs rendered by the server, a "merge" button the host executes, code scanning by the host, server-side blame or language statistics. All impossible unless the host is given the read key, at which point it is no longer zero-knowledge. Substitute: do it in the client or the browser, or in a runner the key holder controls.

1. Taking back what a reader already has. No system can revoke data already fetched. GitHub cannot either: a removed collaborator keeps their clone. What sgit can do is rotate forward (rekey, move), delete the old vault (TM-R12), and with per-folder keys limit what each reader ever received.

1. Per-folder permissions enforced by the host inside one key. The host cannot tell folders apart, and anyone with the key can decrypt every object. Per-folder access needs per-folder keys (section 3), not permissions.

1. Hiding all metadata. Sizes, timing, counts, which ranges a scoped clone reads, and compressibility with blob-deflate (TM-R08, R38, R40, R42). Padding to size buckets, fixed-size packs and decoy range reads reduce the leak, at a bandwidth cost. They never remove it (that would take an ORAM-style protocol).

1. Host-side optimisation of the store. git gc and repacking on the server, deltas the host computes, dedupe across vaults. The host has only ciphertext. Client-side deltas and prune are possible (section 3). Cross-vault dedupe would need convergent encryption, which leaks equality, so we should not want it.

1. A host that enforces fast-forward-only. The host cannot read the ref, so it cannot check ancestry. The client-side rewind guard (shipped) is the answer. A signed, append-only ref log kept by the host would let clients prove a rewind, but not stop a write-key holder from making one.

Everything else in the article's "Git is far ahead" list (merges, staging, blame, bisect, search, identity, GC, deltas, IDE support, and most of review and CI) is client-side in Git and can be client-side in sgit. "Twenty years of maturity" is the one item only time fixes.

5. Suggested edits to the article

1. Replace or source "29 minutes → 4.6 seconds" (abstract, "In short", 0.25.0 bullet, chart).
2. "Signed since 0.19.0" → "signed for months; verified since 0.19.0".
3. "after upgrading to 0.25.0" → "after a fresh clone on 0.25.0".
4. "planned for 0.26.1" → "on dev now as the pre-release 0.26.1.dev0; in the next release".
5. Staging row: add "but sgit write commits named files atomically to HEAD".
6. Identity row and the read-key bullet: add TM-R01 in one line: writing is a host-checked permission, and a signature today proves a key holder, not a particular clone.
7. Index rows and workflow 4: "anchored to its commit, checked under the vault's signature policy".
8. Four GETs: "four for a file at the root, one more per folder; one batch request for a cached path".
9. Leak list: add tree equality, compressibility under blob-deflate, and range positions for scoped clones.
10. Consider adding section 2's list (mirror, repo-carried policy, rewind detection, secret guard, rekey, serve, cache) to "What Git has no equivalent for".

6. Fixes on our side, found while checking

• sgit help all ("full command surface") omits checkout, pack, doctor, remote and the cat / ls / write shortcuts. All of them are in TOP_LEVEL_COMMANDS. Small fix in CLI__Main (around line 1491).
• The limitations page on cli.sgit.ai: signing is not "planned work", and partial commits exist through sgit write. That page is not in this repo.
• 10/27/response__pack-index-verify-field-report.md says "ships in 0.26.1": it ships as 0.26.1.dev0 on dev and in the next release (0.27.0 under the current CI numbering).
• main's CHANGELOG shows 0.26.0 under "Unreleased" until the next merge from dev (already fixed on dev).

This page as markdown · its source, admin/content/research/sgit-and-git-article-review.md