Git keeps a deleted API key because the commit that added it is still reachable

A branch points at a commit, the commit points at a tree, and the tree is a list of names and content hashes ^[5]. Commit the removal and you write a new tree without that name. The old tree still carries the name and the hash, because the old commit still points at it ^[1]. The file is gone from the working tree. Nobody was looking there. Two commands get the value back: one lists every file ever deleted across all refs, the other prints any of them out of the commit that carried it ^[2].

The object count shows the same structure without a secret in it. Three files in one commit, one byte changed in one of them, commit again, and the repository holds eight objects: two commits, two trees, four blobs ^[4]. The blob count stays at four because the second commit's tree reuses the hashes of the two files you did not touch ^[5]. No diff is stored anywhere in that set; `git show` computes one at display time ^[6].

The size question is the one the post treats as hardest, and it answers with measurements. Fifty-one commits appending a line to a 200,000-line file left every object in place, and packing kept a base with a chain of deltas ^[8]. On a second machine running git 2.43.0 the same script gave 24276 KiB loose and 468 KiB packed, one object stored in full and fifty as deltas ^[9]. That is a ratio of about 51.9 to 1 ^[15]. The entire packed history of that file is smaller than one loose copy of it: divide the loose figure by 51 objects and the average is 476 KiB ^[14].

Appending one line at a time to a large text file is close to the best case for a delta chain, and the post says as much: the ratio depends on your git version and on how the file changes, while only the shape holds ^[10]. The claim the measurement actually supports is narrower and more useful: "not deleted" and "not stored twice" are different statements ^[16]. For the 51.9 figure to transfer, your history has to change the way that history changed.

Two corrections in the post are worth copying into your own notes. The reflog window is thirty days for anything your branches can no longer reach, which is always the case after a reset, an amend or a rebase, and the ninety-day window applies to entries still reachable from a branch ^[11]. A fresh clone contains the deleted object and checks out a working tree without it ^[12].

Every number comes out of a bash script the post publishes, which runs `git init` in a temporary directory with `commit.gpgsign` disabled and prints the object counts ^[17]. The author invites readers to run it and post their results with their git version, and wrote: "I would rather fix the article than defend it." ^[13]

That leaves the response to an actual leak. The value is readable in every clone that already exists ^[12], and it is readable because the commit that introduced it is still reachable ^[3]. Making that commit unreachable means rewriting history other people already hold, and you can change the secret without finding them.