A couple of weeks ago, I was talking to a friend about the impeding launch of Discourse. She asked me if I was worried that people would judge me for the code I'd written (although to be honest, you can't tell who wrote what since we reset our commit history when we launched).
The truth is releasing your code is a very scary thing to do. I knew some parts were good, some parts less so.
Posts like this (and their pull requests) have floored me. Grant did a fantastic job refactoring a large chunk of technical debt we'd acquired, and then took the time to write up why he did it in detail.
I really hope this trend of improving something and writing how you did it catches on. I want to see it in other people's code bases too!
Out of curiosity - was there any particular reason you reset your commit history at launch? I feel somewhat impotent when I come across a chunk of code I don't understand the reasoning of and discover that its history dead-ends at the initial release commit.
If it is a clever way to get a bunch of people using Discourse right off the bat by asking questions in the meta forum [1], then it is ingenious and I applaud you!
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.
The truth is releasing your code is a very scary thing to do. I knew some parts were good, some parts less so.
Posts like this (and their pull requests) have floored me. Grant did a fantastic job refactoring a large chunk of technical debt we'd acquired, and then took the time to write up why he did it in detail.
I really hope this trend of improving something and writing how you did it catches on. I want to see it in other people's code bases too!