At $day_job we want to start publishing a subtree of our codebase as open 
source. As we audit and prep more sections of the code base, we'll be 
broadening the subtree(s) that we export, until eventually we want as close as 
possible to the whole thing to be open source.

The resulting public repo would only contain commits from the master branch 
that touch the "open" parts of the tree, so while the result wouldn't be 
complete or coherent, it would produce a "read-only" open source artifact and 
allow us to start sharing code today rather than a year or two years from now 
when the entire code base is audited.

I'm thinking of (ab)using filter-branch from a post-receive hook as a means to 
do this. Does this sound sane, or are there better options?

Specifically, I was thinking of doing the following:

- on pushing into our authoritative repo, we replicate to a second "scratch" 
repo where all the dirty work gets done

- the scratch repo has a master branch, and an initial "open" branch created 
using `git filter-branch`

- a post-receive hook in the scratch repo, given a series of commits A..B on 
the master branch, cherry-picks them onto the "open" branch, producing commits 

- the hook runs `git filter-branch` on the "open" branch over commits A'..B', 
filtering the not-yet-open parts of the tree and dropping empty commits

- the hook pushes the resulting HEAD to a public repo

Thoughts? Closest to this idea that I've been able to find online so far is [1].



To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to