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

Chris Bieneman via llvm-dev
2016-07-27T16:47:29Z

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>