[flagged]
Google copybara: moving code between repositories
41–50 of 70 posts
Re: Google copybara: moving code between repositories
#42I 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 nob…
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).
Re: Google copybara: moving code between repositories
#43Earlier quoted context omitted.
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?
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.
Re: Google copybara: moving code between repositories
#4452+ 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
[deleted]
Re: Google copybara: moving code between repositories
#45Ha! 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!
Re: Google copybara: moving code between repositories
#46Ha! 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…
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.
Re: Google copybara: moving code between repositories
#47[flagged]
Re: Google copybara: moving code between repositories
#48Ha! 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…
> 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.
Re: Google copybara: moving code between repositories
#49Ha! 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…
> 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.
really? I thought Google had paid Perforce for a source license?
Maybe I am wrong.
Re: Google copybara: moving code between repositories
#50Earlier quoted context omitted.
> 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.
really? I thought Google had paid Perforce for a source license? Maybe I am wrong.