Roadmap: feature parity with Git, then more on top (28 Oct 2026)

The message: sgit does just about everything Git does, and then more on top. Git, the client, is the bar. GitHub's features (accounts, verified badges, protected branches, review, CI) belong to a future server product ("SGitHub"), not to the CLI.

Follows: review__article-what-sgit-does-that-git-does-not.md (same folder). That review mixed Git and GitHub features, and proposed an owner-signed signer registry for TM-R01. Under this scope, that registry moves to SGitHub (section 4). Signing becomes what Git does: sign with the key you already have, and let each verifier decide whom to trust.

Extension rule: every new feature is off by default and changes nothing for vaults and clients that don't use it. It is on through a setting, either local or a vault feature (sgit vault format --feature …, the mechanism packs and signatures-required already use). Only a feature that old clients would get wrong sets a minimum client version.

1. Already at parity

These Git commands already have an sgit equivalent.

Working with a clone

Branches, tags and merges

History

Integrity and plumbing

2. Gaps: Git has it, sgit doesn't yet (the CLI roadmap)

All of these run on the client in Git too. None needs a server change.

Priority 1

Priority 2

Priority 3

3. Signing the way Git does it

How Git does it. Git never asks who is allowed. It signs with the key the user already has: GPG (gpg.format openpgp), SSH (gpg.format ssh, signing through ssh-keygen -Y sign and so through ssh-agent and hardware keys) or X.509. It stores the signature in the commit (gpgsig), excluded from the signed bytes. Verification is each verifier's choice: a GPG keyring, or an allowed_signers file of principal → public key. GitHub then adds "verified" on top by matching keys to accounts. That last part is the SGitHub layer, not the CLI.

sgit, the same way:

• Signing.
• Read Git's own settings (git config user.signingkey, gpg.format, commit.gpgsign, tag.gpgsign). A user whose Git signs their commits gets signed sgit commits with zero sgit setup. sgit config can override per vault.
• Sign the way Git does: run ssh-keygen -Y sign -n git (agent and hardware keys work) or gpg --detach-sign. The output is Git's format, so ssh-keygen -Y verify or gpg --verify can check an sgit signature outside sgit.
• Verification.
• check verify, history log --show-signature and vault tag show read the same allowed_signers file Git uses (gpg.ssh.allowedSignersFile), or the GPG keyring.
• Results are Git's: good signature from a listed principal / good signature from an unknown key / bad / none.
• Verifying SSH signatures in-process uses cryptography, which is OpenSSL underneath and already a dependency; ed25519, ECDSA and RSA keys are supported. GPG verification runs gpg, as Git does.
• What stays as it is.
• The per-clone ECDSA key keeps signing every commit. It is the machine signature that agents get with no setup, and signatures-required keeps meaning "every commit carries a valid clone signature".
• The user's signature is a second, optional one. It is what answers "who wrote this", for anyone who keeps an allowed-signers file. That closes TM-R01 for that verifier exactly as far as Git closes it, and that is the bar.
• Compatibility: no gate needed. Checked on the code today:
• A commit JSON with a field the client does not know parses fine (Schema__Object_Commit.from_json accepts unknown keys).
• Clients check the clone signature over the fields they know (commit.json()), so the new field must be excluded from the clone's signing bytes, as Git excludes gpgsig. Then old clients verify the clone signature unchanged and simply ignore the user signature.
• The reserved author_signature field cannot carry it: it is validated as base64 of at most 256 characters, and an SSH or PGP signature is longer, so a client would reject the commit (tested). The signature goes in a new field.
• Signed tags work the same way.
• What it does not do (SGitHub's job later): a list of who may write, carried in the vault; joining and approval; revocation records; "verified" decided by a server.

Size: 3–4 days with tests (SSH first, GPG second), plus CHANGELOG and threat-model rows (TM-R01 gains "closed per verifier with an allowed-signers file").

4. Moved to SGitHub (server-side, later)

These were in the article's "Git is ahead" list or in yesterday's review. They are GitHub's features, not Git's, so they are out of scope for the CLI:

• Accounts and identity: who pushed, keys attached to people, "verified" badges, verification recorded at push time.
• A list of who may write: owner-signed signer registry, join requests and approval, revocation (yesterday's TM-R01 proposal), per-person write tokens.
• Protected branches: required signed pushes, rules enforced by the server.
• Collaboration: review / pull requests, the web merge button, CI triggers, issues.
• The append lane is already a server feature. Its CLI (sgit inbox send/read) belongs in section 5, because Git has nothing like it.

Under zero knowledge, an SGitHub server can do the access parts: tokens, ref ACLs keyed by the hashed ref ids, recording verification. The content parts (review, CI, search) run in the browser or in a runner that holds the key.

5. More on top: what sgit does that Git does not

The second half of the message. Already shipped unless marked.

• The host reads nothing: contents, file names, messages and branch names are encrypted on the client.
• A read key is a capability: publish it, and anyone reads from any static host with no account.
• Fetch one folder by byte ranges from plain storage (pack vaults), each object verified by hash.
• Indexes shipped by the writer, signed and encrypted, checked before use.
• Many agents, one folder each: writes outside the scope are refused by name, and two scoped agents never conflict.
• Custody without access: vault mirror.
• Policy carried by the vault and enforced by every client: format gate, signatures-required.
• Rewind detection on every clone.
• The secret guard (keys and key zips are never committed).
• Key rotation: vault rekey / vault move.
• A computable cache for fixed-cost reads.
• serve, publish.
• pki encrypt to a person.
• To add: sgit inbox for the append lane; cat --vault-key (one file with no clone); Phase 4 ranged reads on pack vaults.

Suggested order

1. 2.1 line-level merge.
2. 2.2 signing with your own key.
3. 2.3 commit <paths>.
4. Then 2.4–2.9, 2.12 (rebase) and 2.13 (worktree) as the priority-2 release.
5. 2.10, 2.11, 2.14 and 2.15 when a workload asks (garbage collection is not needed for now).

Each is an extension: off or invisible until used, and no version gate except 2.11.

This page as markdown · its source, admin/content/research/git-parity-roadmap.md