Blogger Flynt's tests: git can't save uncommitted files, only off-repo backups hold

Recently, a developer posted on Reddit claiming that Claude Code deleted 48,218 of their files in 103 seconds during a "rebuild project mirror" task, also wiping out objects, refs, and logs inside .git. The post was later deleted by the author, though TechRadar and other media reported it. Since there is currently only a first-person account with an attachment verification report and no independent forensics, its authenticity remains unverified. However, this incident raises a more practical engineering question: if a similar accidental deletion happens to you, how much can git actually save?

Independent developer Flynt conducted a series of reproducible drills in a local environment (git 2.34.1, Linux) to challenge the intuition of "I have git, what am I afraid of?" He first simulated the most common disaster scene: everything in the working directory except .git was deleted. After using the standard recovery command git restore ., md5 list comparisons revealed that afternoon edits made but not committed were lost, and new untracked files were completely missing. The conclusion is clear: git only recognizes committed content; uncommitted and untracked files simply do not exist in its recovery worldview.

Next, Flynt tested git stash. Without the -u parameter, stash likewise failed to capture untracked files. Even if one always uses stash -u, the body of the stash is still a set of objects within the .git directory. This touches upon the true cause of death in the incident: .git is not an off-site disaster recovery backup. When a cleanup script deletes from the project root downwards, goes down with it. After Flynt simulated deleting , , and , four commands—, , , and —all returned "not a git repository" errors. Because works by traversing objects, it becomes unemployed when the repository is gone.