I attended the LLVM Dev Meeting in San Jose last week, and I participated in the round-table discussion on the GitHub migration. I don’t think there’s any recording, but here are some related llvm-dev threads too:
- [llvm-dev] New LLVM git repository conversion prototype
- [llvm-dev] Updates on SVN to GitHub migration
- [llvm-dev] Subprojects, GitHub, and the Monorepo
This is going to affect how we manage our LLVM-related submodules. Currently we’re based on the git-svn mirrors, which the LLVM project has published separately for each subproject. Going forward, the Source of Truth will instead look like this llvm-git-prototype, and it’s not clear if they will attempt to maintain the subproject read-only mirrors at all anymore.
One option for Rust is to just maintain our own subproject repos as needed. We rebase relatively infrequently, so an occasional
git subtree split to pull out the paths we care about might be just fine.
We could also consider just embracing the monorepo as one big submodule for Rust. We currently have
src/tools/lldb, and this constitutes the bulk of the monorepo already. The big difference is that the ones in
src/tools are currently optional, but as a monorepo everyone will have to pay the price of that larger
git fetch and local storage.
src/llvm-emscripten, an older fork, but it’s not clear to me how long this will continue to exist, compared to
wasm32-unknown-unknown. And there’s the sub-submodule
src/libcompiler_builtins/compiler-rt which overlaps the monorepo too, but I don’t know if it’s worth trying to merge that.
attn @alexcrichton in particular, since you most often deal with our submodules.