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

Wed Jul 27 09:47:29 PDT 2016

I’m just now catching up on this massive thread after being on vacation last week, and I have a few thoughts I’d like to share.

First and foremost please don’t consider lack of dissent on the thread as presence of consensus. The various git-related threads on LLVM-dev lately have been so active and contentious that I think a lot of people are zoning out on the conversations. As supporting evidence of this, I was discussing this thread yesterday around the office yesterday and had quite a few people responding something along the lines of “they’re proposing what?”.

I think it would be great for us to have several different proposals for how the git-transition could work, and have a survey to get people’s opinions. I know this has been discussed repeatedly, and I want to put in my vote in favor of having a survey that takes into account multiple different approaches.

WRT the actual proposal in this thread, I’m strongly opposed to a mono-repository. While I understand the argument that the full clone’s cost on disk space is minimal compared to an LLVM object directory, what about for contributors that contribute to the smaller runtimes projects but *not* to LLVM or Clang. A contributor that only contributes to libcxx or compiler-rt being forced to do a full clone of all the LLVM projects in order to push a patch kinda sucks.

I want to point out a few workflows people may not be considering.

Clang can be built against an installed LLVM. I know this workflow is used by some people because I’ve broken it in the past and had to fix it. With a mono-repo this workflow gets a bit more complicated because you’d need to do sparse checkouts, and it probably means we should just nuke the workflow entirely because there is no real value added by having it.

Compiler-RT’s sanitizers are used with GCC; no LLVM required. While for the common use case maintaining sparse repository mirrors would limit impact of this on users, should any GCC user want to contribute to Compiler-RT, you’re forcing them to clone a much larger repository than necessary.

The same problem with Compiler-RT’s sanitizers also applies to libcxx, libcxxabi, libunwind, and potentially any other runtime library projects that we may create in the future.

Beyond all that I want to point out that the git multi-repository story is basically the same thing we have today with SVN except for the absence of a monotonically increasing number that corresponds across repositories. While admittedly you do get a linear history with using the mono-repository, that isn’t the only way to solve the problem, and I don’t really think that the benefit (not needing to write some tooling) justifies the increased burden applied to contributors that don’t use the full LLVM family of projects.

I think we have some pretty strong evidence in the form of the github fork counts (https://github.com/llvm-mirror/ <https://github.com/llvm-mirror/>) that most people aren’t using all of the LLVM projects. In fact, by that evidence Clang (the second most popular project) is forked less than 2/3 as many times as LLVM.

-Chris

> On Jul 26, 2016, at 11:31 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 26 July 2016 at 19:28, Sanjoy Das via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>> Even if it were possible, I would still keep my upstream checkout
>>> separate just as a safety measure, to keep from sending private stuff
>>> upstream by accident.
>> 
>> Just FYI, this is our (Azul's) workflow as well, and for similar
>> reasons.
> 
> Same here.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160727/f88b9c73/attachment-0001.html>