Wild times when one can go from a HN post about an interesting open source code to a port to a new language in a matter of hours (wip, but almost complete: https://github.com/theolivenbaum/copybara)
theodpHN 1 hours ago [-]
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
the_dude_ 1 hours ago [-]
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
vlovich123 15 minutes ago [-]
I really doubt copybara ever gets killed. AFAIK it’s a pretty central tool to google3 and how they maintain and vendor OSS projects at scale
dmoy 34 minutes ago [-]
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
klodolph 4 hours ago [-]
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.
rnagulapalle 4 hours ago [-]
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.
madeofpalk 35 minutes ago [-]
> 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?
dmoy 30 minutes ago [-]
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
schrodinger 7 hours ago [-]
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 copying is better than a lot of dependency?
ASinclair 6 hours ago [-]
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.
paulddraper 5 hours ago [-]
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.
xyzzy_plugh 6 hours ago [-]
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.
fipar 3 hours ago [-]
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)
yaskou 2 hours ago [-]
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.
klodolph 4 hours ago [-]
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.
MarkSweep 7 hours ago [-]
Some other interesting tools in the space. Rust is using a tool called Josh to sync commits:
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.
namanyayg 8 hours ago [-]
Nice, I built something similar ~5 years ago using nested git repos and scripts to accomplish a similar purpose of combined private and public repos.
My shell script definitely wasn't google scale tho!
UnfitFootprint 7 hours ago [-]
Yep, same. I thought it might a wrapper around git subtree but looks like it’s doing quite a lot more!
For example altering commit author emails during sync
alok-g 5 hours ago [-]
Interesting. 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.
xyzzy_plugh 6 hours ago [-]
Copybara is one of those things that you should have set up yesterday.
It works great and I've seen many teams gain significant productivity when collaborating in a monorepo with public bits.
If you're even toying with an internal monorepo you owe it to yourself to give it a try.
jumploops 6 hours ago [-]
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?
veyh 2 hours ago [-]
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.
willchen 3 hours ago [-]
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 :)
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
Gitlab has really simple way to mirror from Gitlab to Github or other git vendors/servers
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
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.
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.
Do they not support contributions on the public repos back into the internal monorepo?
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
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 copying is better than a lot of dependency?
Some projects are also developed in the monorepo and exported via Copybara.
My team also uses it to version Starlark rule sets internally.
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.
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.
Say, to rebase upstream MySQL changes onto a fork in the monorepo (in a random, non-specific example)
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?
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...
My shell script definitely wasn't google scale tho!
For example altering commit author emails during sync
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.
It works great and I've seen many teams gain significant productivity when collaborating in a monorepo with public bits.
If you're even toying with an internal monorepo you owe it to yourself to give it a try.
I’m curious what downsides folks have experienced with this tool?
Any tips?