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...
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.
I suppose if you're running some security analysis on code in your own repo, the fact that you've copied the code in means that it'll run on your third party dependencies too, since they no longer appear to be third party.
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.
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
It works well when the assumptions hold, that there isn't large divergence on either side. It can actually be largely automated.
https://dagster.io/blog/monorepos-the-hub-and-spoke-model-an...
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
My shell script definitely wasn't google scale tho!
For example altering commit author emails during sync
Handwritten bash scripts using git-replace and git-filter-repo [1] did a much better job
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?
[file "lib/util.py" from "https://github.com/example/tools.git"]
commit = a1b2c3d4e5f6789abcdef0123456789abcdef01
branch = master
comment = Common utility function
[file "config.json" from "https://github.com/example/tools.git"]
commit = b2c3d4e5f6789abcdef0123456789abcdef012
branch = master
target = vendor
comment = Configuration from tools repo
[file "helper.js" from "https://github.com/another/project.git"]
commit = c3d4e5f6789abcdef0123456789abcdef0123
branch = main
comment = Helper from another project
core.workflow(
name = "default",
origin = git.github_origin(
url = "https://github.com/google/copybara.git",
ref = "master",
),
destination = git.destination(
url = "file:///tmp/foo",
),
# Copy everything but don't remove a README_INTERNAL.txt file if it exists.
destination_files = glob(["third_party/copybara/**"], exclude = ["README_INTERNAL.txt"]),
authoring = authoring.pass_thru("Default email <default@default.com>"),
transformations = [
core.replace(
before = "//third_party/bazel/bashunit",
after = "//another/path:bashunit",
paths = glob(["**/BUILD"])),
core.move("", "third_party/copybara")
],
)
“Fetch and sync individual files or globs from other Git repositories, with commit tracking and local-change protection”
this "mirror and use the local copy" dance is exactly how "any other third party tool" works within google.
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 a bit worried when looking at the git history before making the PR, because there's a lot of Gerrit Change-ID markers (meaning there's some gerrit code review system somewhere which I'm not privvy too) and I might have submitted a PR which never gets upstreamed..
I feel the same pang of pain from the lack of a perforce version of Gerrit/Rietveld.. but, you can't ask for everything!
[0]: https://github.com/google/copybara/pull/347
- 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 acceptable to most people. If anyone is aware of something in Critique's league, I'd love to hear about it!
Edit: I tried to do a reasonably thorough survey a couple of years ago when I left Google and https://codeapprove.com/ was the closest I found, but there were still many gaps.
GitHub's PR review workflow is archaic in comparison, especially now that every page takes 2-3 seconds to load.
This is incorrect. Piper is API-compatible with Perforce but is a totally different implementation, not a fork.
Maybe I am wrong.
There are some variations, but this is generally the same with all open source projects which live in their internal monorepo, such as gVisor or Bazel.