Google copybara: moving code between repositories • Hacker News Board

Re: Google copybara: moving code between repositories

#21

Post by fipar » Wed, Jul 01, 2026, 5:10 AM UTC

xyzzy_plugh wrote: post #9

schrodinger wrote: post #7

To 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 for when you have a monorepo internally, and want to publish parts of it as open source to the world. They still need to live in the monorepo, so this is the solution. Having a public repo as a dependency for your private corporate repo is a pain in the ass development-wise. Having a tree of such dependencies is a migraine.

It can also be used if you want part of your monorepo to track something open source from the world.

Say, to rebase upstream MySQL changes onto a fork in the monorepo (in a random, non-specific example)

Re: Google copybara: moving code between repositories

#22

Post by willchen » Wed, Jul 01, 2026, 5:47 AM UTC

i used this tool when i was at google, extremely helpful in open-sourcing things from google3 to github. still, i'm glad to just directly develop on github now :)

Re: Google copybara: moving code between repositories

#23

Post by veyh » Wed, Jul 01, 2026, 6:40 AM UTC

jumploops wrote: post #11

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?

If you're exporting more than a few commits, I suggest using local repos (/path/to/.git) for both the source and destination. Otherwise it'll be quite slow.

Re: Google copybara: moving code between repositories

#24

Post by yaskou » Wed, Jul 01, 2026, 6:46 AM UTC

fipar wrote: post #21

xyzzy_plugh wrote: post #9

Earlier quoted context omitted.

It's for when you have a monorepo internally, and want to publish parts of it as open source to the world. They still need to live in the monorepo, so this is the solution. Having a public repo as a dependency for your private corporate repo is a pain in the ass development-wise. Having a tree of such dependencies is a migraine.

It can also be used if you want part of your monorepo to track something open source from the world. Say, to rebase upstream MySQL changes onto a fork in the monorepo (in a random, non-specific example)

Yeah, that's the fun part. Probably built first for exporting monolith slices to OSS, but the reverse direction is more interesting to me. Tracking an upstream or keeping a private fork in sync. That's what makes Copybara useful well beyond the monorepo use case.

Re: Google copybara: moving code between repositories

#25

Post by the_dude_ » Wed, Jul 01, 2026, 6:56 AM UTC

If the only need you need is sync repos without exclusions or transformations I wouldn't bother, it could work for you until it doesn't when they archive it or kill it like kaniko or so many other google products/tools.

Gitlab has really simple way to mirror from Gitlab to Github or other git vendors/servers

Re: Google copybara: moving code between repositories

#26

Post by theodpHN » Wed, Jul 01, 2026, 6:58 AM UTC

52+ years of progress... :-)

July, 2026: Google copybara allows one to move code between two prod repositories

March, 1974: IBM COPY allows one to move code between two prod partitioned data sets: OS/MVT and 0S/VS2 TSO Data Utilities COPY, FORMAT, LIST, MERGE User's Guide and Reference https://www.computinghistory.org.uk/downloads/8987

Re: Google copybara: moving code between repositories

#27

Post by wasting_time » Wed, Jul 01, 2026, 7:09 AM UTC

MarkSweep wrote: post #6

Some 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?

git subtree was the OG tool: https://apenwarr.ca/log/20090430

It has since been merged into git proper:

https://manpages.debian.org/testing/git-man/git-subtree.1.en...

https://docs.github.com/en/get-started/using-git/about-git-s...

Re: Google copybara: moving code between repositories

#28

Post by madeofpalk » Wed, Jul 01, 2026, 7:43 AM UTC

rnagulapalle wrote: post #20

klodolph wrote: post #17

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 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…

> 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?

Re: Google copybara: moving code between repositories

#29

Post by dmoy » Wed, Jul 01, 2026, 7:45 AM UTC

the_dude_ wrote: post #25

If the only need you need is sync repos without exclusions or transformations I wouldn't bother, it could work for you until it doesn't when they archive it or kill it like kaniko or so many other google products/tools. Gitlab has really simple way to mirror from Gitlab to Github or other git vendors/servers

yea copybara is really for doing transforms in one or both directions.

E.g. translating from external bzl to internal blaze BUILD compatibility, changing between external imports and internal third_party style imports, etc etc.

If it's a pure mirror, copybara is super overkill

Re: Google copybara: moving code between repositories

#30

Post by dmoy » Wed, Jul 01, 2026, 7:49 AM UTC

madeofpalk wrote: post #28

rnagulapalle wrote: post #20

Earlier quoted context omitted.

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…

> 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