The commit was gone, but the data was still there—locked behind field-level encryption you couldn’t ignore. Resetting the repo was simple; protecting sensitive fields was not. That’s the edge case where "git reset"and strong encryption meet, and where most projects bleed risk.
Field-level encryption means encrypting specific data fields instead of entire files or databases. In source control, this is the difference between exposing private keys in commit history and making them unreadable even if old commits leak. Whether you are rolling back bad code with a hard git reset --hard or cleaning history with git reset --soft, encrypted fields stay secure. No checkout, branch switch, or reset leaves them in plain text.
When you run git reset, Git moves HEAD to a different commit. It rewrites your working directory depending on the mode—soft leaves changes staged, mixed unstages them, hard wipes them. The problem: reset cannot delete what’s in Git’s object database if you haven’t run git gc or force-pushed. Any sensitive data committed—even once—can be restored. Field-level encryption mitigates this by ensuring that if those fields resurface, they are ciphertext, not exposed secrets.