Live data from Hacker News

Google copybara: moving code between repositories

github.com

31–40 of 70 posts

Re: Google copybara: moving code between repositories

#31

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

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

Re: Google copybara: moving code between repositories

#32

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

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.

Re: Google copybara: moving code between repositories

#35

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

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

Re: Google copybara: moving code between repositories

#36
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

Re: Google copybara: moving code between repositories

#37

Earlier quoted context omitted.

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

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.

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!

Re: Google copybara: moving code between repositories

#39
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".
Post reply on HN