I work at Google and copybara workflows are the bane of my existence.
Google copybara: moving code between repositories
61–70 of 70 posts
Re: Google copybara: moving code between repositories
#62Ha! This post comes right at the time where I finally got around to open sourcing the patches I made to provide Perforce support which I use at my gamedev studio[0]. I find it kind of funny that perforce support was not included, only git support seems to exist in any meaningful way: despite the primary use of copybara being for releasing internal google code (which lives in Piper, a fork of Perforce). I actually got…
One reason there's no Perforce support for Gerrit/Rietveld is that Google doesn't use those tools for changes to code that's stored in Piper. Instead, they use Critique: - https://abseil.io/resources/swe-book/html/ch19.html - https://read.engineerscodex.com/p/how-google-takes-the-pain-... I haven't found anything external that's as good, and am astounded that GitHub's incredibly lackluster PR review tooling is accept…
Gerrit's new UI comes pretty close, and it's also what Google uses for projects living outside of google3.
GitHub's PR review workflow is archaic in comparison, especially now that every page takes 2-3 seconds to load.
Re: Google copybara: moving code between repositories
#63Some other interesting tools in the space. Rust is using a tool called Josh to sync commits: https://josh-project.dev The blog post from the Rust people: https://blog.rust-lang.org/inside-rust/2026/06/04/how-josh-h... Meta used to have an open source tool called fbshipit. But according to its open source repo they no longer use it: https://github.com/facebookarchive/fbshipit Any others in this space?
Yeah I vibe coded https://github.com/sluongng/capyfun during a hackathon recently to add a generative transformation layer on top of the traditional imperative transformations.
Re: Google copybara: moving code between repositories
#64Earlier quoted context omitted.
it's useful for cases like google's, where they mirror internal code to github or vice versa, and the two versions need a bit of mechanical work every time they are synced (e.g. slightly different tree layout conventions, internal code or docs that you don't want to include in the github version, stripping of references to other internal stuff like bug IDs from comments, etc).
But if you are gonna extract and open-source the whole self-contained tool, why not just do that and then install in whatever project like you install any other 3rd party tool?
in order to use third party code within google it needs to be copied into the monorepo, and projects that depend on it need to import the internal version. this requires at the very least setting it up to build via blaze (google's internal build system, open sourced as bazel), and frequently adjusting its directory layout to fit the monorepo conventions.
this "mirror and use the local copy" dance is exactly how "any other third party tool" works within google.
Re: Google copybara: moving code between repositories
#65Very nosily, I'm curious what prominent projects Google hosts OSS but has a meaningfully private internal version.
Re: Google copybara: moving code between repositories
#66Been 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 developmen…
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 ge…
[flagged]
Re: Google copybara: moving code between repositories
#67Ha! This post comes right at the time where I finally got around to open sourcing the patches I made to provide Perforce support which I use at my gamedev studio[0]. I find it kind of funny that perforce support was not included, only git support seems to exist in any meaningful way: despite the primary use of copybara being for releasing internal google code (which lives in Piper, a fork of Perforce). I actually got…
One reason there's no Perforce support for Gerrit/Rietveld is that Google doesn't use those tools for changes to code that's stored in Piper. Instead, they use Critique: - https://abseil.io/resources/swe-book/html/ch19.html - https://read.engineerscodex.com/p/how-google-takes-the-pain-... I haven't found anything external that's as good, and am astounded that GitHub's incredibly lackluster PR review tooling is accept…
Codeapprove creator here! I made it to fill the exact gap you're lamenting, and I still think that gap exists. For a while it seemed like Graphite was going to be the answer but over time they ended up focusing more on the AI angle and less on human review tooling and now it feels just as cluttered and slow as anything else.
I home some other Xoogler comes along and delivers a Critique build for 2026, I still think there's a need!
Re: Google copybara: moving code between repositories
#68Been 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 developmen…
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 ge…
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
Re: Google copybara: moving code between repositories
#69Earlier quoted context omitted.
It’s largely used for syncing external open source projects with the monorepo. Policy is to require source code imports over built artifacts. Though you can get exceptions. Some projects are also developed in the monorepo and exported via Copybara. My team also uses it to version Starlark rule sets internally.
I suppose it mitigates the potential risk of libraries being poisoned?
It's mostly to track licensing, at least initially. The supply chain angle is a happy coincidence.
Re: Google copybara: moving code between repositories
#70Earlier quoted context omitted.
The rust blog post covers this. Subtree performance is terrible on larger repos and they didn’t land something that would fix it on medium sized ones. That’s why they went with a better maintained solution that scales.
Plus Josh seems to do waaay more - dynamically exposing monorepo directories as a separate repo. I wish all the effort into things like JJ and Pijul was going into solving those sorts of things instead!
Pijul natively handles monorepos btw, that's the whole point.