Home / Articles / What sgit does that Git does not / Versions / v1.1.0
What sgit does that Git does not: what changed in v1.1.0
From v1.0.0 (2026-10-27, 6ede018fc) to v1.1.0 (2026-10-28, a6d0c117b), paragraph by paragraph.
48 paragraphs added, 16 removed, 11 changed in place, 47 unchanged. About 1,810 words added and 547 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: Between 3 and 27 October, sgit shipped ten releases, and each one fixed a bottleneck that a real workload had found. A one-file commit on a 76,000-file vault went from 29 minutes to 4.6 seconds; a pull of a 300-file pass on 228,000 files from 566 to 31.7 seconds; a one-folder clone of a pack vault from 36 to 2.8 seconds. The ideas came from earlier work of mine: MGraph-DB's cross-references, Memory-FS's reads by offset, caching on content addresses, and the rule that the writer pays. It is time to stop describing sgit as "like Git". This is the map of what sgit does that Git does not, what Git also has, where Git is clearlyahead ahead,today and how little of that is out of reach, and what is designed but not yet shipped. The sgit CLI team reviewed it against their code, and it is corrected and extended from their review.
6 unchanged paragraphs, under In short {#in-short}
• Git has no equivalent for encrypted names and messages, read keys, blind writes, or byte-range folder reads from plain storage.
• Git has it too: partial clones, shallow clones, no-checkout clones and kept packs. My memo over-claimed these.
• Git is far ahead on merges, identity, its ecosystem and maturity.
• Next, not now: reading one file with no clone, and websites whose files come from vaults.
• Git has no equivalent for a host that reads nothing, read keys, custody without access, policy the vault enforces on every clone, blind writes, or byte-range folder reads from plain storage.
• Git has it too: partial, shallow and no-checkout clones, kept packs, and committing named files. My memo over-claimed some of these.
• Git is ahead today on line-level merges, per-person identity, deltas and garbage collection, and its tooling. Almost all of it is client-side, so it can be built.
• A few things are out of reach by design: anything the host would have to read, and taking back what a reader already has.
• Next, not now: one file from a pack vault with no clone, and websites whose files come from vaults.
• Reviewed by the sgit CLI team against their code, and corrected.
3 unchanged paragraphs, under Every bottleneck becomes a release {#releases}
The sgit-ai package on PyPI shows ten releases in that window, from 0.17.0 on 3 October to 0.26.0 at 01:26 UTC on 27 October. The early ones were about the network: keep-alive connections, fetching each shared sub-tree once, a full clone in one parallel sweep. The middle ones were about trust in history: a format gate, signedsignature commitsverification checked onthat every client,sgit client enforces in a vault that requires it, rewinds refused, signed tags, undo and amend. The last three are where the numbers changed by orders of magnitude.
1 unchanged paragraph
• 0.25.0, the cost follows the change, 26 October. A flat-map cache, a scan cache built on Git's own index rule, and a commit that rebuilds only the folders on the changed file's path. On a 76,000-file vault, a one-file commit went from 1,739 seconds to 4.6.4.6, as cli.sgit.ai's build agent measured it for the release notes; on the newsroom's own 79,465-file vault, the CLI team's record has it going from 4 minutes to 9 seconds.
• 0.26.0, index packs, 27 October. Every data pack now carries an index pack beside it, and the client can keep packs whole and fetch one folder by byte ranges. A pull of a 300-file pass on 228,000 files went from 566 to 31.7 seconds,seconds (measured under a profiler, which inflates both; the ratio stands), and with the indexes to 16.9.16.9 in a plain run.
2 unchanged paragraphs
And it has not stopped. A fix now on adev branch,as plannedthe forpre-release 0.26.1,0.26.1.dev0, and in the next release, takes pack index verify from 1,002 seconds to 3.5 on 24,000 files, after the newsroom's researcher measured the released version at about 57 seconds a pack.
4 unchanged paragraphs, under Minutes to seconds, with the caveats {#numbers}
• There was a regression. The first status after upgradingthe upgrade to 0.25.0 took 18 minutes 23 seconds on the curator's 4.2 GB pack clone, because the new scan cache hadwas tobuilt readby reading every file onceof a freshly written clone, almost all of it waiting on a slow session disk. 0.26.0 fixed it by seeding the cache on every write.
12 unchanged paragraphs, under Where the speed came from {#lineage}, Stop comparing sgit with Git {#framing}
!shot sf-map.webp | images/ | What sgit does that Git does not, what Git also has, wherewhat Gitcan isbe ahead,built, and what isnever next.can. | chart
1 unchanged paragraph, under What Git has no equivalent for {#only-sgit}
• The host reads nothing. Contents, file names, commit messages and branch names are encrypted on the client. The closest Git add-on, git-crypt, says in its README that it "does not encrypt file names, commit messages, symlink targets, gitlinks, or other metadata". The honest edge: sgit's host still sees sizes, timing and object counts, and in pack mode which commit each push carried.
• A read key is a capability, not a permission. A read key is derived from the vault key by a one-way function, so it can never become write access, and it works from any static host with no account. GitHub's read role is enforced by a server you have to trust, and it can be revoked; sgit's cannot be revoked after the fact. And it is per vault, not per folder: "A partial clone is not an access boundary", says sgit's limitations page, so the answer today is a vault per folder.
• Write without read. An append lane lets a sender put something into a vault and learn nothing, not even whether anyone else writes there: the answer to a write is {"ok": true}. No Git or GitHub role can write without reading. This is a server feature, with no sgit command of its own yet.
Grouped by what they give you. The sgit CLI team's review added four of these, which I had missed.
Privacy and access
• The host reads nothing. Contents, file names, commit messages and branch names are encrypted on the client. The closest Git add-on, git-crypt, says in its README that it "does not encrypt file names, commit messages, symlink targets, gitlinks, or other metadata". The honest edge, in full: the host still sees sizes, timing and object counts; which trees are equal; in pack mode, which commit each push carried and which files share a folder; with compression on, how compressible each file is; and, for a scoped clone, which byte ranges it reads.
• A read key is a capability. It is derived from the vault key one way, so it never becomes write access, and it works from any static host with no account. Writing, though, is a permission the host checks, not cryptography. A read-key holder who can also write to the store can make history that verifies, which is the threat model's top accepted risk. It is per vault, not per folder: "A partial clone is not an access boundary", says sgit's limitations page, so the answer today is a vault per folder.
• Rotation, and moving house. sgit vault rekey and sgit vault move give a vault a new key, and optionally a new server, going forward. Nobody can revoke a clone someone already has, in sgit or on GitHub.
• Custody without access. sgit vault mirror copies and verifies a published vault without its key. A backup service or a second host can hold the vault, check it, and learn nothing.
Trust carried by the vault
• Policy the vault enforces on every clone. The format gate (the minimum client, the features in use) and signatures-required live in the vault's encrypted branch index, and every sgit client enforces them at clone and pull, before it writes anything. In Git, signature checks are each user's local settings; a repository cannot require them of whoever clones it.
• Rewinds refused on every clone. A remote head that does not descend from the last one accepted is refused by name, unless you pass --accept-rewind. Git's default fetch takes a forced update with one line of output.
• A secret guard. A commit refuses vault keys, zips carrying keys, and links in the tree pointing at secrets.
• Indexes shipped by the writer, signed and encrypted. Git's commit-graph and pack indexes are fast, mature and built locally, as trusted plaintext caches. sgit's index packs travel with the data, anchored to their commit and checked under the vault's signature policy before use (an unsigned index is accepted unless the vault requires signatures), and a bad one is skipped. As the threat model puts it, "An index is a plan, never a proof."
Reading and writing on plain storage
1 unchanged paragraph
• Indexes shipped by the writer, signed and encrypted. Git's commit-graph and pack indexes are fast, mature and built locally, as trusted plaintext caches. sgit's index packs travel with the data and are checked against the commit and its signature before use; a bad one is skipped. As the threat model puts it, "An index is a plan, never a proof."
• Encrypt a file to a person, inside the store. sgit pki encrypt --recipient seals a file to someone's public key. Git signs commits; it has no "encrypt this to that person" inside the repository.
• A read path that skips the walk. sgit cache add <path> puts a hot file at a location only key holders can compute, read in one request, for an edge function or a page.
• Any static host, or none. sgit serve runs the vault's browser and API locally in a container; sgit publish and serve --static lay a vault out for any host that answers a GET. A reader with the read key needs no account and no server code.
• Write without read. An append lane lets a sender put something into a vault and learn nothing, not even whether anyone else writes there: the answer to a write is {"ok": true}. No Git or GitHub role can write without reading. It is a server feature; the sgit command for it is still to come.
• Writes shaped for agents. sgit write <path> --also <path> --push --json commits named files straight to the head, atomically, and publishes them in one call, without scanning the working copy; checkout --since-pull writes only what changed.
• Seal a file to a person. sgit pki encrypt --recipient writes a file sealed to someone's public key, which you then commit. Git signs; it has no "encrypt this to that person".
5 unchanged paragraphs, under What Git has too, and my memo over-claimed {#git-has-it}
• Shallow clones, private branches and signed commits all have Git equivalents.
• Committing named files. sgit has no staging area and no hunks, but sgit write commits the files you name, atomically, and leaves other edits alone: Git's git commit <paths>, in the form an agent needs. The limitations page's warning about "committing three of seven changed files" is out of date.
• History tools. history log with --grep, --since, --until, --author, --file, --patch and --stat; history diff, show, reflog, undo, revert and reset; commit --amend, stash and signed tags.
• Shallow clones, private branches and signed commits all have Git equivalents, and sgit has them: clone --depth, fetch --unshallow, combinable with --path, and a key per clone.
1 unchanged paragraph
Where Git is clearly ahead {#git-ahead}
• Merges. Git's default merge detects renames and merges line by line. sgit's merges are whole-file, with conflict files.
• Staging and partial commits. sgit refuses them by design; its limitations page says, plainly, "If your workflow depends on committing three of seven changed files, sgit will fight you".
• Identity. GitHub knows who pushed, protects branches per person, and signing keys can expire and be revoked. sgit's signatures say which clone wrote a commit, not who is allowed to write.
• Storage and ids. Git has delta packs and garbage collection; sgit has no pruning yet. Git's ids are 160-bit by default; sgit's format 1 is 48-bit, and format 2, 128-bit, is opt-in per vault.
• The ecosystem and maturity. Forges, review, CI, search, blame, bisect, every IDE, and twenty years of stability. Most of it needs a host that can read the content, which is exactly what sgit refuses to have.
Where Git is ahead today, and how much of it can be built {#git-ahead}
These are real gaps, and most are minor or mid-level for the way we use sgit: workflows that are not common for agents writing documents and data. Almost everything here runs on the client in Git too, on plaintext the client already has, so it can be built in sgit the same way. The CLI team's review sketches how for each one.
• Merges. Git merges line by line and detects renames; sgit merges whole files and writes a conflict file. A line-level three-way merge on the client is the biggest visible gap, and a medium-sized job.
• Hunk-level staging. Named files, yes (sgit write); parts of a file, no.
• Who may write. GitHub knows who pushed, protects branches per person, and its signing keys expire and can be revoked. A signature in sgit today proves that some key holder wrote a commit, not which clone, and there is no per-key expiry, only rotating the whole vault. An owner-signed list of allowed signers is designed.
• Storage. Git has delta packs and garbage collection. sgit has neither yet; for pack vaults, pack compact moves superseded packs to an archive, which is part of the answer. Git's ids are 160-bit by default; sgit's format 1 is 48-bit, and format 2, 128-bit, is opt-in per vault.
• Tools. Blame, bisect, grep over content, IDE support, review and CI. All but the hosted parts are client-side in Git too.
• Maturity. Twenty years of it. Only time fixes that one.
What a host that reads nothing can never do {#limits-of-the-model}
A few things are out of reach by design, not by effort, and each has a client-side substitute:
• Anything the host would have to read: server-side search, diffs, a merge button, scanning. Do it in the client, the browser, or a runner that holds the key.
• Taking back what a reader already has. No system can; GitHub cannot either. sgit rotates forward.
• Per-folder permissions inside one key. The host cannot tell folders apart. Per-folder access needs per-folder keys, which are designed.
• Hiding every piece of metadata. Padding and decoy reads reduce the leak; they never remove it.
• Optimising the store on the host, and a host that enforces fast-forward only. The client does both jobs instead: client-side deltas and pruning, and the rewind guard that ships today.
2 unchanged paragraphs, under Next, not now: one file with no clone, and websites from vaults {#next}
• Hitting a file directly. On a normal vault this already works: a file is four plain GETs of fixed paths,works, from any static host, GitHub Pages included.included: four plain GETs for a file at the root, one more for each folder above it, and one batch request for a path declared with sgit cache add. history log --vault-key already runs with no clone; a cat that does is a small addition. What is not shipped is reading one file from a pack vault by byte range with no clone at all. The 0.26.0 notes say so: Phase 4 "is not in this release", though the offsets it needs are already written into every pack.
3 unchanged paragraphs, under The workflows where this matters {#workflows}
1. Many agents on one very large vault, one folder each. Each agent clones its folder; its commits outside the folder are refused by name; agents in different folders never conflict; the host learns nothing about the contents. In Git you can get close with partial clones and sparse-checkout, but you need a server that reads everything.
2. Give a reader read-only access to encrypted material, with no account. Publish a read key; the reader fetches from a static host. This site publishes read keys for its vaults on purpose.
3. Let an agent deposit into someone's inbox without being able to read it. An append lane, with the payload sealed to the recipient's public key.
4. Trust an index without trusting the host. Every index is verifiedanchored againstto a signedits commit and checked under the vault's signature policy before it is used.
5. Hand a vault to a backup host that cannot read it. vault mirror copies and verifies it, keyless.
6. Make a vault's rules travel with it. Require signatures, or a minimum client, and every clone enforces it.
3 unchanged paragraphs, under What this does not claim {#limits}
• sgit's own documentation is partly out of date. Its limitations page still says commit signing is "planned work", though commits have been signed for months and verified since 0.19.0, and itsthat partial commits are not possible, though sgit write does them. On main, the 0.26.0 notes still sit under an "Unreleased" headingheading; indev has the changelog.fix.
1 unchanged paragraph
Reviewed, and corrected {#review}
The sgit CLI team reviewed this article on 28 October against their code at 640069a: the source, every command group's help, the changelog, the threat model and their response notes. Their verdict: accurate on the whole, too strong in sgit's favour in two places, and underselling it in several. What changed:
• The 29 minutes. They could not find it in their records. It is in cli.sgit.ai's 0.25.0 release notes, measured by that site's build agent on its own 76,000-file vault, so it stays, attributed, with their own figures beside it.
• Two claims were too strong: that a signature says which clone wrote a commit (it proves a key holder), and that every index is checked against a signed commit (it is checked under the vault's signature policy, which may not require one). Both now say so.
• Several were too weak. sgit commits named files (sgit write), reads one file with no clone on a normal vault, rotates keys, mirrors vaults it cannot read, carries its policy to every clone, refuses rewinds, and guards against committing secrets. All of that is above now.
• Smaller fixes: commits were signed long before 0.19.0, which added verification; the 18-minute status was the cache's first build on a fresh clone; the pack index verify fix is on dev as 0.26.1.dev0; the 566-second pull was measured under a profiler; a file deep in folders takes more than four requests; and the list of what the host sees is longer.
The review is on the record, with an answer to each finding.
1 unchanged paragraph, under Where this comes from {#sources}
sgit's release notes for 0.24.0, 0.25.0 and 0.26.0; cli.sgit.ai's articles pack indexes, shipped, indexes the writer pays for, indexes in the pack, is there any overhead?, pack mode in four rounds and keys the way Git does it; its docs on partial clones, history integrity and limitations; the sgit CLI repository's changelog, response notes and threat model, read on 27 October 2026; PyPI release times; the PHP October 2026 newsroom's briefs on pack mode, 0.25.0 and 0.26.0; Git's documentation on git-clone, pack format and commit-graph; GitHub's documentation linked above. Two figures are cli.sgit.ai's own, credited in their captions. Related: you can feel good engineering, explorer coding, a team frozen in time. The sgit CLI team's review of this article, 28 October 2026, on the record. Written up by this site's agent, newsroom.writer; the editorial responsibility is mine.