What does HackerNews think of copybara?

Copybara: A tool for transforming and moving code between repositories.

Language: Java

You can potentially use CopyBara https://github.com/google/copybara

We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.

We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)

I haven’t seen much info regarding their setup, aside from the bits about Pants and Bazel.

Are those actually the upstream repositories, though? And is it known how they interact with them?

Google has Copybara [1], which allows portions of a monorepo to live outside as an entirely separate repository without the need for things like Git submodules. It supports synchronization of histories, pull requests, path and file transformations, etc.

In that sense, something like Copybara would allow them to, relatively, easily open source those bits, receive outside commits, and then sync the changes back to the monorepo.

[1]: <https://github.com/google/copybara>

Facebook uses a monorepo, similar to the way Google does it. Dependencies are vendored and checked into the repo. Facebook has released a tool for migrating software between repos, which is much like Google's Copybara:

Facebook's fbshipit: https://github.com/facebook/fbshipit

Google's copybara: https://github.com/google/copybara

With these tools, you can make fairly sophisticated choices about how you do vendoring. You can make the internal version look just like the public version, in terms of commit history. And you can export internal commits to public commits, stripping out confidential information along the way (or integrations with internal systems and tooling).

In somewhat related news, Gerrit has a new frontend and it's awesome! Google has a couple of UX people working on it now and it shows.

As a big fan of patch-based code review, I still can't stand GitHub PRs. It's very annoying to stack GitHub PRs, so the default is to create large PRs instead. This is sad, because smaller units of review result in better code! Gerrit solves this (and much more).

Example change on Gerrit (click on "Comments"):

https://gerrit-review.googlesource.com/c/gerrit/+/303182

Reasons to use Gerrit in spite of the learning curve:

- Ability to review commit messages (they're part of the codebase!).

- Show diffs between different versions of a change, even across rebases, with inline comments.

- Inline comments aren't lost on rebases and will be ported.

- Changes can be easily stacked.

- Select code snippets for inline comments, not just lines.

- It's really fast and there's keyboard shortcuts for everything.

- Rebase and cherry pick to release branches from the UI.

Some projects like Go, Cue or SQLAlchemy use custom tooling or Copybara[1] to mirror PRs to Gerrit, which seems like the best of both worlds - simple PR workflow for drive-by contributions, patch workflow for core contributors who work with it all day.

[1]: https://github.com/google/copybara

I have never used this tool but Google open-sourced Copybara[1]. If you look at the commits of their other open-source repositories, it seems this tool is often used.

[1] https://github.com/google/copybara

From what I understand, the two tools have some very significant differences at this point. They may be the same codebase in a broad sense, and may share a lot of code, but I bet they are using something like Copybara to synchronize them.

https://github.com/google/copybara

1) This is mostly dependent on language and the rules available. In our case python is a mess regarding 2/3 compatibility and external dependencies. There is a roadmap being executed on to fix these issues. Regarding our transition, it was slow at first as we pulled in services and tackled some tech debt. We wrote a handful of custom rules that helped. Bazel does have the ability to import repositories and that can be used as a little bit of a crutch in the process.

2. Exactly the same process except there is a single pr instead of multiple across multiple repositories.

One of our challenges was integrating one of our public repos into our repo and that is more of a difference in release patterns(semantic versioning vs nightlies). We use copybara to help with this problem.

- https://github.com/google/copybara