[edverma2]

All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.

[ramon156]

If I'm honest, I don't know how much this happens at work, and even if it does it's not the end of the world. Just scratch the commit from existence.

In my head, the people who accidentally share secrets are also the people who couldn't setup trufflehog with a precommit.

[Arainach]

This isn't true in practice. Even among well educated high performing professionals, mistakes happen. Checklists save lives - in medicine, in aircraft maintenance, in all fields.

People who believe they know what they're doing get overconfident, move fast, and make mistakes. Seasoned woodworkers lose fingers. Experienced doctors lose patients to preventable mistakes. Senior developers wipe the prod database or make a commit they shouldn't.

https://hsph.harvard.edu/news/fall08checklist/

>In a study of 100 Michigan hospitals, he found that, 30 percent of the time, surgical teams skipped one of these five essential steps: washing hands; cleaning the site; draping the patient; donning surgical hat, gloves, and gown; and applying a sterile dressing. But after 15 months of using Pronovost’s simple checklist, the hospitals “cut their infection rate from 4 percent of cases to zero, saving 1,500 lives and nearly $200 million,”

[oreilles]

> Just scratch the commit from existence.

Unfortunately, that is impossible: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

[Cthulhu_]

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

[bapak]

pre-commits require discipline:

- enforce them on CI too; not useful for secrets but at least you're eventually alerted

- do not run tasks that take more than a second; I do not want my commit commands to not be instant.

- do not prevent bad code from being committed, just enforce formatting; running tests on pre-commit is ridiculous, imagine Word stopping you from saving a file until you fixed all your misspellings.

[ali_piccioni]

I moved all my precommit hooks to prepush hooks. I don’t need a spellchecker disrupting my headspace when I’m deep into a problem.

My developer environments are setup to reproduce CI test locally, but if I need to resort to “CI driven development” I can bypass prepush hooks with —-no-verify.

[emmelaich]

One good (and obviously bad) thing about Subversion was the ability to change history. As admin I was asked numerous times to change a commit message. To point to the correct Jira issue, for instance.

Also easier to enforce pre-commit, since it was done server side.

[SAI_Peregrinus]

A CI system can run the precommit hooks, and fail if any files are changed or the hooks don't exit successfully.