Don't dump 375 files with 68000 lines of code without Git commit history

[xor-freenet]

See e5f9ef7.

Proper documentation is worth at least half of the quality of a codebase.
Erasing the Git history means arbitrarily ripping out half of the documentation.

How is anyone supposed to work upon that codebase if they can't figure out why it is the way it is?

It's a shame that this seems to have become the standard for "we're open sourcing this proprietary piece of software". If you don't want to hand out the full codebase then perhaps just keep this small rest of it to yourself as well.

[cori]

"When we know the history and context of a codebase, it stops being something that happened to us, and instead we become its steward."

-- https://twitter.com/kerrizor/status/972663493227823105

[christophertino]

I agree with what you’re saying. For us though, open sourcing presented a few complex challenges. Our old repo was tied into several projects, and we had private info in there like our Chrome, Firefox, and Edge build keys, AWS keys for our internals tools, etc. Admittedly, these were things that never should have been in the working tree but had snuck in over the years. Also for copyright reasons we needed to remove the tracker db files, which were also part of the old project.

We hoped to partially make up for the loss of commit history by providing thorough documentation. @zarembsky annotated every part of the project to JSDoc standards. You can build those with npm run docs and I invite you to check them out.

This is the first part of a larger open-source push for us. We’ll be opening up our build tools, Safari extension, iOS and Android apps, and more over the next few months. We’re also figuring out how to rework our tracker db and combine it with the work Cliqz has done on https://whotracks.me, and make that open as well.

To sum it all up, we’re treating this project as a fresh start for Ghostery, with community involvement to help us make a better product.

[xor-freenet]

@christophertino

I agree with what you’re saying. For us though, open sourcing presented a few complex challenges. Our old repo was tied into several projects, and we had private info in there like our Chrome, Firefox, and Edge build keys, AWS keys for our internals tools, etc. Admittedly, these were things that never should have been in the working tree but had snuck in over the years. Also for copyright reasons we needed to remove the tracker db files, which were also part of the old project.

Thanks for the reply!

Nothing prevents you from changing git history using one of these:

• git rebase to change commit history interactively. This allows you to both edit commit messages and also squash individual commits together to get rid of private information which was first committed and then removed.
• git format-patch in a shell script to dump all commits as patch files, then edit the commit messages / code manually in the files, and committing all of the files by a script afterwards.

Of course that is a lot of work - but understanding a codebase without history also is :|