We’re in the process of open-sourcing a few sub-projects within a monorepo, and didn’t know this existed!
I’m curious what downsides folks have experienced with this tool?
Any tips?
Google copybara: moving code between repositories
11–20 of 70 posts
Re: Google copybara: moving code between repositories
#12That seems like a tool easily adoptable by folks engaging in dark patterns on GitHub, particularly the malware bait repos.
Re: Google copybara: moving code between repositories
#13To those who have used it: is it handy for situations where you have multiple repos that want to share a little code, but it's not worth the trouble of extracting a library, referencing it, publishing versioned releases, updating dependent repos, etc? And instead just "sync" a code folder from one main repo (perhaps containing common domain models) to other repos? Basically the Go philosophy that a little bit of copy…
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.
Source code imports versus artifacts really neither here nor there. Go is source code imports too.
The key part for Copybara is that Google will make changes to the OSS projects from within the internal repo and everyone else will make changes to the OSS projects.
Re: Google copybara: moving code between repositories
#14Interesting. Anyone knows how this compares to using git submodules and subtrees?
I had used those to create separate repo for website artifacts while the same also remain plugged into the webapp dev repo. (Both sides remain modifiable and changes mergeable to the other side.)
Thx.
Re: Google copybara: moving code between repositories
#15If you are using Jujutsu you can achieve a basic way to maintain a public repo from a private monorepo with very little code and without Copybara. I wrote up how to do it here: https://vihren.dev/blog/20260625-jj-public-private-workflow/
Re: Google copybara: moving code between repositories
#16If you are using Jujutsu you can achieve a basic way to maintain a public repo from a private monorepo with very little code and without Copybara. I wrote up how to do it here: https://vihren.dev/blog/20260625-jj-public-private-workflow/
The main function of copybara is not moving code but modifying code to make it suitable for a different repository structure, build system, etc.
Re: Google copybara: moving code between repositories
#17Been 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.
Re: Google copybara: moving code between repositories
#18To those who have used it: is it handy for situations where you have multiple repos that want to share a little code, but it's not worth the trouble of extracting a library, referencing it, publishing versioned releases, updating dependent repos, etc? And instead just "sync" a code folder from one main repo (perhaps containing common domain models) to other repos? Basically the Go philosophy that a little bit of copy…
Copybara can do that but I think it will be annoying and tedious to use it that way. More annoying than the problem of extracting a library or shoving some files in a separate repo.
Re: Google copybara: moving code between repositories
#19[flagged]
Re: Google copybara: moving code between repositories
#20Been 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 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.