[llvm-dev] [RFC] One or many git repositories?
Dean Michael Berris via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 29 01:00:19 PDT 2016
> On 29 Jul 2016, at 06:41, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote:
> For cross-repository changes I am fairly certain you could construct something that can be pushed to a try bot based on the submodule repository. There is no technical reason that shouldn’t work, and I don’t even think the scripting around that would be terribly complicated. Admittedly that is more complicated than just writing a pull request to a single repository, but I suspect not much. I may look into that.
>> In contrast, as discussed earlier, if people want a multirepo-like
>> setup based on the monorepo, we can reduce this to a single command
>> run once when the repository is cloned. It ends up being far less
>> fragile, and requiring far fewer (actually, zero) tricks on the server
> The only thing a monorepo gets you that strictly isn’t possible without it is the ability to commit to multiple projects in a single commit. Personally I don’t think that is a big enough justification, but that is my opinion, not a fact.
As someone who's recently had to change LLVM, Clang, and compiler-rt with interlocking interdependent changes (and I suspect a lot more people do this than just me), I would offer a dissenting opinion. It's *too hard* and *too much work* to get cross-cutting changes like these to vertical projects like XRay which spans clang, llvm, and compiler-rt.
It will certainly advantage similar efforts (say, like the coroutines work) if there was a single repo and changes to the runtime, front-end, and back-end just happen normally -- and that _no acrobatics will be required to accomplish them_.
Consider things like the builtins library -- you add a new built-in intrinsic in LLVM, then in the same commit have that builtin implemented in compiler-rt along with the tests on both sides.
A mono-repo will be a strict improvement over the status quo or any other formulation involving submodules.
More information about the llvm-dev