Hacker News Reader

Comment by ramilexe | Hacker News Reader

Why?

Because who knows what kind of private company information might possibly be leaked otherwise in commit messages. From a legal point of view, it's a lot easier to start with a clean slate.

Not everyone does, the UnrealEngine doesn’t for example, you can see project code words in the commit history.

Not as sensitive as accidentally dropping information about your internal network. then take the long-troll method of infiltrating an upstream provider to attack a juicy target (build system of fortune 500? yes please)

or maybe catching wind of some dev keys that really are root keys..

many reasons to sanitize git history before open sourcing. in fact many organizations i have worked with still maintain two separate repos, one internal and one open source using fancy magic (either with git or with additional tools) to sanitize and sync commits between the two. i've seen code commits to a large organization that are then packaged up and inspected for license and security violations in an untrusted environment.. many reasons to keep two (or more) running copies

Security wise: From a tactical standpoint - your obvious ones are access keys, etc. From a strategic standpoint, I can tell who did what - and the people actually become great attack vectors.

Also great recruitment vectors for competitors

Argument in the past: Because the best alternative is a complete audit of all past commits for IP issues, trade secrets, keys, network internals, ... It's just much easier to remove that hurdle from the process and only look at the current state of the code.

    git commit -am "hope this works"

or my favorite

git commit -am "i did a stupid"

Reply on news.ycombinator.com