Honestly it came down to there being private keys and other shifty things in there at various points. Also there was a lot of old crap as we evolved the prototype closer to what we released... We just thought it was a good idea.
This was a SOP at a company I worked at, for any repository, either for OSS or when delivered as work product to customers. We just didn't want to have to do a commit-by-commit, line-by-line audit for any of an unbounded universe of Things That Would Be Very Bad If They Leaked. A surprising amount of them are not things that are technical in nature -- for example, many developers treat commit messages as watercooler talk between themselves rather than something which could potentially be reviewed in a courtroom. (Guess the precipitating event: "Memo to all developers: One should never, ever, ever, ever, ever mention a developer who is no longer with the firm in a commit message.")
> (Guess the precipitating event: "Memo to all developers: One should never, ever, ever, ever, ever mention a developer who is no longer with the firm in a commit message.")
Is the purpose here to limit the amount of material that might show up in discovery, and therefore potentially be made public?
If X was made redundant rather than fired for incompetence, and then commits were to mention that X was a terrible developer, then if X sues for unfair dismissal, then you've just given X evidence that the company lied.