Bulk History Rewriting

## The mental model people get wrong Newcomers picture a repository as "the current files, plus a log of changes". It is closer to the opposite: a repository is a content-addressed store of immutable objects, and history is a chain of full snapshots over that store. Removing a file and committing produces one more snapshot in which the file is absent. It does not, and cannot, edit snapshots that already exist. ## The objects involved - A **blob** holds the raw bytes of one version of one file, named by the hash of its content. - A **tree** is a directory listing: names mapped to blobs and to other trees. - A **commit** points to one root tree plus its parent commit(s). Because every object is named by its own hash, an object cannot be modified in place — changing the bytes would change the name. So the only way to make history not contain something is to build a *different* history. ## Why the delete commit is not enough Say `config.yml` was added in commit A and deleted in commit Z. Commit Z's tree simply lacks that entry. Commit A's tree still has it, and commit A is still an ancestor of Z, so the blob is still **reachable** — reachable meaning: walk from any ref (branch, tag, HEAD, reflog entry) through commits, trees and blobs, and you arrive at it. Reachable objects are exactly the objects Git keeps, and exactly the objects a clone or fetch transfers. You can prove it in seconds: - `git log --all --oneline -- config.yml` still lists the commits that touched it. - `git show A:config.yml` still prints the file. - `git rev-list --objects --all` still enumerates the blob. ## What .gitignore and branch deletion do not do `.gitignore` only stops *untracked* files from being staged casually; it has no effect on content already committed and no retroactive effect at all. Deleting a branch removes one ref, but the commits may still be reachable from other refs, and even if they are not, they linger in the reflog and in packfiles until `git gc` prunes them — which by default only prunes objects past a grace period. ## What actually removes it Three things must all happen: 1. **Rewrite every commit that contained the content.** Git cannot edit a commit; it can only create a replacement with different content and a different SHA, plus replacement descendants for everything downstream. `git filter-repo` does this across the whole ref graph. 2. **Drop the old references.** Reflogs, `refs/original/` backups left by older tooling, and stale tags all keep the old commits alive. `git reflog expire --expire=now --all` removes those handles. 3. **Garbage-collect.** `git gc --prune=now` deletes objects that are now unreachable. `git filter-repo` performs steps 2 and 3 itself at the end of a run. ## The part that is not technical Even a perfect rewrite only fixes the copy you rewrote. Every other copy — teammates' clones, mirrors, forks, backup snapshots, CI caches, a laptop that has been offline for a month — still has the original objects, and each one is a complete repository. So the honest answer in an interview is: rewriting history reduces future exposure, it does not undo past exposure. If the content was a credential, it is compromised from the moment it was pushed, and the first action is to invalidate that credential; the rewrite is cleanup that follows. ## The one exception worth naming If the content is only in the commit you just made and nothing has been pushed or fetched by anyone, you are not rewriting shared history at all — you are fixing a local tip, which is cheap. The moment it is published, the cost becomes a coordinated rewrite for everyone.