[llvm-dev] [RFC] One or many git repositories?

[Dean Michael Berris via llvm-dev]

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