Several rounds of digging in the same sandbox, and twice the measurement itself was wrong: counting the bin misses things, and the UI’s counts can scare you. What finally killed my hypothesis was a timestamp.
All of this happened inside one sandbox that quietly rewrote deletion as “move to Recycle Bin”, which broke a git repository six times — the full story is in “WorkBuddy Will Corrupt Your Git”. This post is only about the mistakes my own measurements made along the way.
To find out whether an action was intercepted, the direct approach is watching the Recycle Bin for new entries. I started by counting totals: once before the command, once after. That method produced one confident and wrong conclusion, namely that a certain deletion had gone through untouched. It turns out every removed file comes with a metadata record whose write is delayed, so counting the moment a command returns usually misses it.
Switching to comparing sets of entry names flipped the answer: that operation was intercepted after all. Same phenomenon; change how you measure it and the verdict flips.
A habit I picked up afterwards: once I have a hypothesis, I try to knock it down myself first. I suspected the pack indexes were lying about their contents, so I compared each pack’s index entry count with the objects it actually held. The six packs held 17,805, 113, 20,524, 315, 17,269, and 20,471 objects; every one matched its index, 76,497 in total, and the hypothesis died on the spot.
What finally stopped me was a timestamp. The unreadable commit was created at 18:29, while the last pack file was written at 15:20. It postdated every pack, so logically it could not be inside any of them. That one observation was worth more than all the pack counting before it.
01The index broke, the files didn’t
The scariest moment was believing the whole workspace had been wiped. After cleaning out a quarantine directory the tooling reported 2,672 pending entries, which looks exactly like a collapsed filesystem. Not one file was missing: find counted 2,610 and so did git ls-tree -r HEAD. What had broken was .git/index, truncated to 362 bytes, leaving git ls-files with a single record, whose lone survivor was a nine-megabyte binary.
One more had nothing to do with tools; I just jumped to a conclusion. One day pushes kept failing with an SSL connection cut by unexpected eof, followed by three dead remote queries. I concluded that someone’s proxy had died, and wrote that conclusion into my report. The reply came back: my proxy is fine. A retry succeeded immediately, 200, in 0.65 seconds.
Since then, any conclusion that points at something outside my own code gets cross-checked first with a command that doesn’t depend on it. Looking back, every one of these mistakes was in how I was checking: the counting method, the UI’s numbers, my own judgement.