[newjersey]

I'll go further: never* rewrite public history

*In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it.

Are there secret keys in your app that you can't invalidate without a lot of pain? Maybe it is time to change some things in your app.

Maybe if someone accidentally commits secret-evil-plan.txt you might want to rewrite history? I can't think of any other scenarios... I mean even if someone commits a secret key, you're probably better off revoking it and leaving the secret key there. Or should you delete that file anyway to prevent people trying to brute force your old revoked private key?

[JimDabell]

> *In most cases, I think we should consider invalidating secret keys instead of trying to delete it and hope nobody saw it.

Absolutely. AWS secret keys accidentally pushed to GitHub are abused within a few minutes. There's essentially no window where published keys remain safe.

[planteen]

That's for a public repo. I'd bet the vast majority of companies have private repos.

[eskimobloood]

Depends on what is "public" history. Is a branch where you working on alone public, or does it become public after merging in back to master. Squashing a branch before merging back depends a lot of the discipline of the commiter. So for a branch with commits like "add FeatureX", "arg forgot this edge case", "ups another fix", "finally it works" it makes a lot of sense to squash it. While for "add FeatureX", "fix some linter errors during development" it makes then to leave the history as it is.