Docs / Concepts

sgit for git users

If you know git, you know most of sgit. Same verbs, same mental model — with three deliberate differences that exist because the payload is encrypted.

The Rosetta stone

gitsgitNotes
git initsgit init--existing vault-ifies a non-empty folder
git clone <url>sgit clone <vault-key>the key is URL + auth + decryption in one
git statussgit status--explain teaches the branch model
git commit -amsgit commit -malways whole-folder — there is no staging area
git push / pull / fetchsgit push / pull / fetchpush is delta + ciphertext only
git logsgit history log--oneline, --patch, --json, ranges
git diffsgit history diff--remote, --commit, --files-only
git showsgit history showread-only — fetches missing objects without merging
git revert / resetsgit history revert / reset
git stashsgit vault stashpop, list, drop
git branch / checkoutsgit branch new / switch / checkout
git merge conflictssgit resolve --showthree-way base/ours/theirs view with a verdict per file
git remotesgit remote add / list / set-url
git fscksgit check fsckverifies encrypted object integrity, can repair

The three differences that matter

1. No staging area

Every commit snapshots the whole folder. This removes git's most confusing concept, and it fits the security model: partial staging would leak "which parts changed" into workflows that are supposed to be opaque. Use branches where you would have used the index.

2. The vault key is URL, auth, and encryption key in one

passphrase:vault-id. There is no separate remote URL to configure, no separate credential to manage, and no password reset. Whoever holds the key holds the vault — treat it like the private key it is.

3. Two layers of branches

You never work directly on a shared branch. Every clone works on a private clone branch (its key never leaves your machine) and push forwards commits to the shared named branch. That's why two agents on the same vault can't corrupt each other's work-in-progress. The full story →