And just to be clear. IF you’ve ever checked in sensitive info into a git repository, do NOT make that repo public.
git rm wrangler.toml; git commit -s -v is not sufficient. It’s extremely difficult to forensically scrub sensitive data from git history. Which is a good thing ™ if you’re ever concerned about accidentally deleting something. Git will save you 99% of the time.
Unfortunately, the propensity for data retention is your enemy with sensitive data. It’s honestly easiest, and fails safe, to just tar up a release of the infected repo, and untar into a new, empty repo.
If you’re interested in understanding what makes git so sticky with your data, I recommend reading Git from the Bottom Up. In short, as long as anything references the blob which contains the sensitive information, that data still exists in the history. So, if you checked in the sensitive file in the first commit, you would have to rewrite that commit, and every commit since to remove the reference to the sensitive file. Which will mess up all of your git tags, and that’s just for your main development branch. You’d also have to delete the tags, and make sure you track any time you renamed the file and catch those too. Running
git gc --prune=now --force Still won’t put you in the clear. There’s references to that damn blob in
.git/logs/* So you’ve got to scrub that as well. And don’t forget any time you’ve stashed your work.
So yeah, just don’t post that publicly. Use a clean repo for that task.
/me just had bad flashbacks of scrubbing repos so we could retain the history without the devil-blob .
 Without the sensitive data, of course