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

via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 7 10:30:25 PDT 2016


Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:

> Right, we actually have a proposal to take what is in the current SVN
> repo here: http://llvm.org/svn/llvm-project/ and migrate this to a
> single repository.
> I was not sure if you were referring to this proposal (monorepo) or to
> the recent emails about “external libraries” that GCC uses like gmp
> and mpfr. 
>
> You can find more details here: https://reviews.llvm.org/D24167
>
> If you have some good reasons why you would think a proposal would be
> problematic to you, or one would better fit your workflow, feel free
> to expose them now.

It could be problematic for us depending on how the monorepository is
structured.  We reference the LLVM git repository directly and use it to
migrate to new versions, pick patches, etc.  If LLVM proper were part of
a larger repository that becomes more difficult to do because the commit
file paths won't match.  We'd be back to essentially manual diff+patch
which is quite a step backward from the smoth git-oriented process we
use now.

The document says that the individual git repositories will remain.
Does that mean the monorepository is using git-submodule to manage the
aggregate repository?  If so that should work for us.  I'm more
concerned about the case where the individual repositories' histories
were interwoven into a single repository and the individual repositories
went away.

I have extensive experience transitioning a very large project from a
set of individual repositories to a single repository where we interwove
the individual histories.  It was the right direction for us but I don't
think it would be for LLVM.

I completely understand the benefits of a monorepository.  One of the
biggest for us was the ability to git-bisect across components.  How
does git-bisect work with submodules?  I have very little experience
with submodules but would like to learn more.

                              -David


More information about the llvm-dev mailing list