alt.hn

6/30/2026 at 11:45:39 PM

Google copybara: moving code between repositories

 https://github.com/google/copybara

by reconnecting

7/1/2026 at 1:16:24 AM

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?

by MarkSweep

7/1/2026 at 7:09:47 AM

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

by wasting_time

7/1/2026 at 8:06:23 AM

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.

by vlovich123

7/1/2026 at 9:48:58 AM

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!

by IshKebab

7/1/2026 at 5:09:14 PM

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.

by sluongng

7/1/2026 at 1:31:08 AM

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?

by schrodinger

7/1/2026 at 2:03:42 AM

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.

by ASinclair

7/1/2026 at 9:16:39 AM

I suppose it mitigates the potential risk of libraries being poisoned?

by lwhi

7/1/2026 at 10:26:50 AM

Well kind of, or you just end up copying the poisoned version directly into your repo rather than having it as a dependency. Same outcome.

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.

by baliex

7/1/2026 at 2:58:23 AM

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.

by paulddraper

7/1/2026 at 2:04:21 AM

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.

by xyzzy_plugh

7/1/2026 at 5:10:36 AM

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)

by fipar

7/1/2026 at 6:46:17 AM

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.

by yaskou

7/1/2026 at 4:21:20 AM

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.

by klodolph

7/1/2026 at 10:45:40 AM

Ha! 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 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

by dijit

7/1/2026 at 12:56:25 PM

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

by bruckie

7/2/2026 at 11:21:35 AM

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!

by habosa

7/1/2026 at 4:03:01 PM

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.

by lima

7/1/2026 at 11:26:36 AM

> which lives in Piper, a fork of Perforce

This is incorrect. Piper is API-compatible with Perforce but is a totally different implementation, not a fork.

by Arainach

7/1/2026 at 10:59:40 AM

Don't worry, they accept PRs on that repo. They just merge them internally and then re-export them.

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.

by lima

7/1/2026 at 4:17:11 AM

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.

by klodolph

7/1/2026 at 4:45:33 AM

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.

by rnagulapalle

7/1/2026 at 7:43:50 AM

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

by madeofpalk

7/1/2026 at 7:49:18 AM

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

by dmoy

7/1/2026 at 1:39:38 PM

The "supported" workflow is you keep your source of truth in either the monorepo or the external repo. Then you export the current state of the source of truth to keep the mirrors up to date. Then, since we can assume the mirrors are up to date, the inverse transform can be applied to import change requests from the mirrors.

It works well when the assumptions hold, that there isn't large divergence on either side. It can actually be largely automated.

by eddd-ddde

7/2/2026 at 1:50:58 AM

[flagged]

by scritty-dev

7/1/2026 at 6:58:26 AM

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

by theodpHN

7/1/2026 at 12:31:24 AM

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!

by namanyayg

7/1/2026 at 1:09:47 AM

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

by UnfitFootprint

7/1/2026 at 6:56:40 AM

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

by the_dude_

7/1/2026 at 8:04:13 AM

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

by vlovich123

7/1/2026 at 7:45:14 AM

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

by dmoy

7/1/2026 at 3:08:52 AM

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.

by alok-g

7/1/2026 at 1:42:47 PM

The main benefits you get are transformations. You can leverage tooling to automate include remapping and things like that.

But it's definitely not geared towards forks, but rather mirrors with deterministic and invertible transforms.

by eddd-ddde

7/1/2026 at 2:07:08 AM

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.

by xyzzy_plugh

7/1/2026 at 9:33:37 AM

At my previous company we tried to use this tool to sync parts of the code between two different git repos. The tool turned out being unacceptably slow.

Handwritten bash scripts using git-replace and git-filter-repo [1] did a much better job

[1]: https://github.com/newren/git-filter-repo

by nbobko

7/1/2026 at 2:38:34 AM

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?

by jumploops

7/1/2026 at 6:40:55 AM

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.

by veyh

7/1/2026 at 8:23:43 AM

Does this tool allow changes in both repositories? (with a 3 way merge strategy) git subtrees come close, but I have a use case where I need transformations/file filters on top.

by Gehinnn

7/1/2026 at 3:56:44 PM

I work at Google and copybara workflows are the bane of my existence.

by DisagreeAndQuit

7/1/2026 at 9:55:49 AM

Does anyone know if it is useful for bidirectional sync between codeberg and GitHub?

by whirlwin

7/1/2026 at 4:14:22 AM

If 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/

by neprotivo

7/1/2026 at 4:15:50 AM

The main function of copybara is not moving code but modifying code to make it suitable for a different repository structure, build system, etc.

by j2kun

7/1/2026 at 8:15:48 AM

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)

by theolivenbaum

7/1/2026 at 1:58:51 PM

Why doesn't it have a capybara as its logo!

by ape4

7/1/2026 at 2:42:41 AM

That seems like a tool easily adoptable by folks engaging in dark patterns on GitHub, particularly the malware bait repos.

by syngrog66

7/1/2026 at 5:47:43 AM

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 :)

by willchen

7/1/2026 at 12:42:48 AM

Cute name. (Naming is hard and important.)

by lysace

7/1/2026 at 12:45:39 AM

That tune is in my head again... again...

by whh

7/1/2026 at 6:55:12 PM

Very nosily, I'm curious what prominent projects Google hosts OSS but has a meaningfully private internal version.

by nixosbestos

7/1/2026 at 3:25:14 PM

I already shared git-fetch-file in another comment here, but the .git-remote-files manifests seem a lot nicer than whatever this thing does:

    [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
vs

    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")
        ],
    )
There seems to be an absolute ton of reference at https://github.com/google/copybara/blob/master/docs/referenc..., whereas I feel like all the people using git-fetch-file just want files from other repos, and sometimes to make some changes on those.

by bellowsgulch

7/1/2026 at 10:06:11 AM

[flagged]

by yahavthehackern

7/1/2026 at 4:32:18 AM

[flagged]

by shizuhalabsai

7/1/2026 at 11:19:56 AM

[flagged]

by Srikann

7/1/2026 at 10:04:37 AM

I get it that there are use-cases for this, but it's surprising to learn that apparently use-case space is big enough for it to invite a creation of a dedicated tool. I mean that the fact you need it is a bit shameful on its own, no? Usually, when you need to reuse the code between the projects, you try to extract it as a separate library / module. The copying between repos is just a lazy solution, because "ain't nobody got time for that".

by krick

7/1/2026 at 10:22:12 AM

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).

by zem

7/1/2026 at 2:31:29 PM

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?

by krick

7/1/2026 at 5:40:43 PM

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.

by zem