Three dominant themes in the discussion
| Theme | Summary | Illustrative quote |
|---|---|---|
| 1. Existing tooling for syncing code across repos | Participants note that similar solutions (git‑subtree, Josh, fbshipit, etc.) have long been used to move or mirror code between monorepos and external repositories. | “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.” – namanyayg |
| 2. One‑way export/mirroring to avoid dependency overhead | The most common use case described is exporting a slice of a monorepo to a public repo (or vice‑versa) so teams can treat the code as “copied” rather than maintain a formal library dependency. | “It can also be used if you want part of your monorepo to track something open source from the world.” – fipar |
| 3. Practical concerns: performance, transforms, and alternatives | Users warn that naïve sync tools can be slow, require custom transforms, and sometimes bite‑size scripts (e.g., git‑filter-repo) outperform heavierweight systems. They also point out that Copybara is overkill for pure mirrors but invaluable when path remapping or header stripping is needed. |
“If you're even toying with an internal monorepo you owe it to yourself to give it a try.” – xyzzy_plugh “The one‑way pattern is actually how Google uses it internally too…” – neprotivo |
Takeaway – The conversation revolves around established patterns for moving code between monorepos and external repos, the specific niche of one‑way exports to sidestep dependency management, and the pragmatic trade‑offs (speed, transform support, and alternative implementations) that dictate whether Copybara‑style tools are adopted.