Grixel keeps full history on purpose: nothing you commit is silently lost. That is usually what you want — but it means deleting a file is not the same as erasing its past. This page covers how removal actually works, and what to do about a secret or a huge file committed by mistake.
#Committed a secret? Rotate it first
If you committed API keys, passwords, or tokens, treat them as compromised and rotate them now — revoke the old ones and issue new ones. This is the real fix.
Removing the file from Grixel afterwards is good hygiene, but it is never a substitute for rotating: by the time it was committed, the secret was on the server, may have synced into other people's checkouts, and may already be in a backup or have been read. Rotation is the only thing that actually makes the leak safe.
#Removing a file going forward
To stop a file being part of the project from now on, delete it and submit:
grixel rm path/to/file # stage the removal
grixel submit -m "remove path/to/file"After this the file is gone from the current version of the project. A normal checkout or sync won't have it anymore.
#But history still has the old versions
Deleting from the current version does not remove the file from earlier revisions. The old content is still there and still readable at the revision where it existed:
grixel cat <ref> path/to/file@<old-rev> # still returns the old content
grixel show <old-rev> # still lists itThat has two implications:
- A secret removed this way is still recoverable by anyone who can read the ref and knows (or finds) the older revision. This is exactly why rotating the credential is the step that matters.
- Storage isn't reclaimed. A large file deleted from the tip still occupies space at every revision that referenced it. Removing it from the current version does not shrink the depot.
#Purging content from history
Actually erasing content from history — so the bytes are gone from the server and the storage is reclaimed — is a server operation, not something you do from your own checkout. It is deliberately restricted and destructive, so it is handled by whoever runs your Grixel server.
If you need content genuinely purged (a leaked secret's bytes, or a large file eating storage), contact your server administrator with the ref and path involved. Today the server-side tools for this are coarse — reclaiming content means retiring a whole ref and running garbage collection on the stopped server — so an admin will weigh that against the history you'd lose. A finer, per-file purge is an administrator-only capability under active development; for now, the combination of rotating the secret and deleting it from the tip is the practical answer for most people, with a full purge reserved for cases that truly need it.
#Large files: prevent them up front
The cleanest fix for large-file mistakes is not to commit them in the first place. Use ignore presets so build output and caches never enter the depot, and preview an import before you commit to it:
grixel init -ref <ref> -m "import" -ignore godot,macos,git -n -v # dry run: list every fileSee Large files and locking for working with the big assets you do want to keep, and Getting started for ignore presets and the import dry run.