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

David Chisnall via llvm-dev
2016-07-21T09:51:30Z

On 21 Jul 2016, at 07:12, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
>> I don't much care which of those is chosen. I have a slight
preference for
>> #1, for ease of doing things like grep/log/etc on llvm by itself,
excluding
>> all the other projects. But either way seems probably fine, and an
>> improvement over multiple repositories.
>
> I don't have a strong preference, but #1 proponents weakly convinced
> me with two arguments:
>
> 1. it is easier to mix-and-match repositories as you like
>
> I'd still symlink as I do today, but I can see why this would be
> interesting for off-tree users.
>
> 2. it "makes more sense" to let Clang *use* LLVM instead of LLVM
*host* Clang
>
> this seems more preference than anything, but people that know CMake
> more than I do said it would be "easier" and I trust them. I have
no
> technical arguments pro or against.
>
> Though, I'd be fine with anything really.

First of all, thank you very much for driving this Renato.  It’s a horrible task
to do and I’m very grateful that you’ve taken this on.

I would, however, like to add one argument against a single repo model.  If you
look at the current LLVM GitHub repo, GitHub is tracking 806 forks.  It is
tracking 595 forks for clang.  Not everyone using git for downstream development
has a fork on GitHub.  In particular, GitHub does not allow private forks of
public repos, so anyone who has a non-public git fork of LLVM will have done a
git clone and a git push to their own private repo (on or off GitHub).  I know
of about a dozen such private repos and (for some bizarre reason) most companies
don’t tell me about the secret things that they’re doing with LLVM so there are
undoubtedly a lot more that I don’t know about.

Conservatively, I would estimate that we have at least a thousand downstream
forks of the current LLVM git repository.  Moving to a single repo model with
break all of them.  It is completely unacceptable to break so many downstream
consumers unless we are able to provide them with some coherent migration plan,
but I have not seen anyone in the single-repo camp suggest anything.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/fccc4f19/attachment.bin>