4 ms·
Why?
by ramilexe 7y ago
Why?
- trevor-e 7y agoBecause 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.
- sargram01 7y agoNot everyone does, the UnrealEngine doesn’t for example, you can see project code words in the commit history.
- o-__-o 7y agoNot 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
- czbond 7y agoSecurity 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.
- paxys 7y agoAlso great recruitment vectors for competitors
- joshmn 7y agogit commit -am "hope this works"
- xeromal 7y agoor my favorite git commit -am "i did a stupid"
- jkrems 7y agoArgument 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.