Wincent Colaiuta <win@xxxxxxxxxxx> writes: > 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` Who controls when "authoritative" to "scratch" transfer happens? Using post-receive-hook in "authoritative" sounds like a sensible way to do this. > - 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 A'..B' Are there mechanisms to add commits to the "scratch" repository other than the one that relays the changes from "authoritative"? If so, post-receive in "scratch" may be inevitable, but otherwise, I do not know why you need this processing triggered by the post-receive in the scratch. Wouldn't it suffice to make the post-receive in the "authoritative" do all of these? I did not see anything wrong doing what you described in the post-receive, even though having the hook in the "scratch" felt strange, as the "copying from authoritative" would also want to be automated and the natural triggering mechanism to do so would be a post-receive there. What issues were you worried about? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html