[krick]

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

[zem]

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

[krick]

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?

[zem]

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.