HushGit vs git-crypt

What git-crypt actually is

git-crypt is a Git smudge/clean filter driven by .gitattributes. Files matching a configured pattern are encrypted with a symmetric repository key on commit and decrypted on checkout. That repository key lives in a key file; collaborators get access either by sharing the key file directly or by adding a GPG-wrapped copy per recipient.

What git-crypt protects

• Contents of files explicitly marked encrypted in .gitattributes.
• That same content as it travels through any Git remote — origin sees only ciphertext blobs.
• Access can be granted per GPG key without a central server.

What git-crypt does not protect

• File names and paths. The directory tree, including which paths are encrypted, is plaintext in every commit.
• Commit metadata. Author, committer, timestamps, and commit messages are plaintext.
• Refs and branch names. Branch and tag names are plaintext on the remote.
• Unmarked files. Anything not matched by a .gitattributes pattern ships in the clear. A misconfiguration silently leaks.
• Review and collaboration. Pull requests, comments, issues, CI logs, and access events live on the host, in plaintext, on whatever platform you push to.
• Revocation. Removing a collaborator does not retroactively protect history they already cloned; rotation requires a key change and a re-encrypt of affected blobs.

Where HushGit's design differs

• Whole-repo confidentiality. Pack contents, manifests, refs, and commit metadata are encrypted client-side; the server stores opaque chunks and signed events.
• Encrypted review surface. Pull requests, review threads, and access changes are part of the encrypted protocol, not a separate plaintext layer on a host UI.
• Device-keyed access with rotation. Access is granted per device key with revocation and an append-only signed audit log of access changes, rather than per long-lived GPG identity.
• Witnessed server-state proofs. Current hosted state is accepted only after checkpoint, witness, subject-map, inclusion, private-opening, and local-pin verification.
• No "did I forget the gitattributes line." There is no in-tree allowlist of what to encrypt; everything in the repository is encrypted by construction.
• Server is in the threat model. A compromised HushGit server yields ciphertext and metadata-bounded indexes, not readable code.

You already have a Git workflow and platform you're happy with, and you only need to keep a small set of files (secrets, customer data, key material) confidential from the host. git-crypt is mature, dependency-light, and stays out of the way. It is not trying to be a code platform and that is a feature.

Your threat model includes the hosting provider, your code itself is the sensitive asset, and review, access changes, and CI all need to stay confidential — not just the contents of a few files.

Composing them

git-crypt and HushGit are not mutually exclusive. A team using HushGit as the platform can still use git-crypt inside the repo to compartmentalize secrets between collaborators who all have repo access — HushGit hides the repository from the host, git-crypt hides specific files from each other.