Hacker News Reader

Comment by klodolph | Hacker News Reader

Been using this for a while, mostly when I make a tool as part of a larger project and the tool is big enough to deserve its own release.

It’s powerful enough to do a whole bidirectional shipping operation where you export and import code—no thanks, that’s a hassle. I use it mostly for a simple fire and forget export, where I take a folder out of its original repo and preserve the history. Then I just move development to the new repo. The new project layout can be completely different, but Git blame works and I’m happy with that.

View on HN

The one-way pattern is actually how Google uses it internally too, syncing outward from their monorepo to GitHub. Bidirectional gets messy because transforms (path remapping, file exclusions, header stripping) are easy to apply in one direction but can't always be cleanly inverted. When both sides have diverged, Copybara's baseline tracking starts producing confusing results because semantically equivalent commits generate different SHAs after transform.

One thing worth knowing: history "preservation" is actually cherry-picks with rewritten commits, not a true transplant. Git blame works because the file content and authorship carry over, but the SHAs are new. Copybara embeds the original SHA in a commit message trailer (GitOrigin-RevId), which is useful to know if you ever need to correlate commits across repos after the fact.

> The one-way pattern is actually how Google uses it internally too, syncing outward from their monorepo to GitHub

Do they not support contributions on the public repos back into the internal monorepo?

There are three ways I've seen it done, though it being Google I assume there's more

One is to try the bidirectional support with copybara itself, thought that usually requires more effort than it's worth.

Another is to have the external repo be the source of truth and then always import into google3. Kythe used to do this at least, though I gather it's not done that way anymore.

The third is to just replicate the patches externally (which is pretty easy to automate or semi-automate on a case by case basis), and verify that a re-copybara-export keeps zero diff

The "supported" workflow is you keep your source of truth in either the monorepo or the external repo. Then you export the current state of the source of truth to keep the mirrors up to date. Then, since we can assume the mirrors are up to date, the inverse transform can be applied to import change requests from the mirrors.

It works well when the assumptions hold, that there isn't large divergence on either side. It can actually be largely automated.

Didn't Google have a tool for this called MOE (Make Open Easy) like 15 years ago? I remember it from some of my open source contributions to Guice

Reply on news.ycombinator.com