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

[Justin Lebar via llvm-dev]

> So to get those benefits without the unnecessary complexity of sparse checkouts, I would like it setup so I *don't have to build* all the extra pieces even if they exist in the source tree.  [...]  If the cmake run can do that for me, I have no problem with a unified repo that holds the entire LLVM universe in it.

This is absolutely on the table as far as I'm concerned.  In a world
with separate repos it might make sense to use the presence or absence
of particular source files to trigger building (or not) a particular
project, but that makes little sense with a monolithic repository.

(I mean, it doesn't personally affect me because I never type plain
"ninja" -- I always do "ninja check-clang" or whatever.  But that's
just *my* messed up workflow.  :)

-Justin

On Thu, Jul 21, 2016 at 10:48 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
>
>
>> -----Original Message-----
>> From: Justin Lebar [mailto:jlebar at google.com]
>> Sent: Thursday, July 21, 2016 6:15 PM
>> To: Robinson, Paul
>> Cc: mehdi.amini at apple.com; Renato Golin; llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] [RFC] One or many git repositories?
>>
>> > Developer time, barrier to entry for new contributors.  Getting the
>> sparse-checkout business right looks like it is actually non-trivial and
>> not recommended for the git novice.
>>
>> It's eminently copy-pastable, and there is no possibility of data loss.
>>
>> I understand it's not zero cost, but I have trouble seeing how there's
>> a meaningful comparison between
>>
>>  - the cost of three copy-pastable commands run once, versus
>
> once per clone (picky, picky, picky...) but extra steps are always
> the ones you forget to do.  Scriptable, so maybe not a big deal.
>
>>  - the benefit of simplifying the git commands we all run tens or
>> hundreds of times a day.
>
> Personally I already have a script to deal with updating the entire
> tree; adapting to submodules would be a one-time-ever cost and I
> never think about it again (and never have to retrain my fingers).
>
> I'll acknowledge that people have different workflows, and there are
> advantages to the unified repo beyond what 'checkout' costs.  The
> size cost of the extra sources is relatively small.  So to get those
> benefits without the unnecessary complexity of sparse checkouts,
> I would like it setup so I *don't have to build* all the extra pieces
> even if they exist in the source tree.  Build time is iteration time
> is lost time when building pieces I don't need or care about.  Ditto
> the time taken to run the tests of all those pieces I don't care about.
> This should be a configuration-time thing (which again I have scripted
> and therefore don't have to retrain my fingers).  If the cmake run
> can do that for me, I have no problem with a unified repo that holds
> the entire LLVM universe in it.
> --paulr
>