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

[Robinson, Paul via llvm-dev]

> -----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