Re: [PATCH 1/4] gitfaq: add advice on monorepos

[Philip Oakley <philipoakley@iee.email>]

On 20/10/2021 02:06, brian m. carlson wrote:
> Many projects around the world have chosen monorepos, and active
> development on Git is ongoing to support them better.  However, as
> projects using monorepos grow, they often find various performance
> and scalability problems that are unpleasant to deal with.
>
> Add a FAQ entry to note that while Git is attempting improvements in
> this area, it is not uncommon to see performance problems that
> necessitate the use of partial or shallow clone, sparse checkout, or the
> like, and that if users wish to avoid these problems, avoiding a
> monorepo may be best.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  Documentation/gitfaq.txt | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt
> index 8c1f2d5675..946691c153 100644
> --- a/Documentation/gitfaq.txt
> +++ b/Documentation/gitfaq.txt
> @@ -241,6 +241,32 @@ How do I know if I want to do a fetch or a pull?::
>  	ignore the upstream changes.  A pull consists of a fetch followed
>  	immediately by either a merge or rebase.  See linkgit:git-pull[1].
>  
> +Design
> +------
> +
> +[[monorepos]]
> +Should we use a monorepo or many individual repos?::
> +	This is a decision that is typically made based on an organization's needs and
> +	desires for their projects.  Git has several features, such as shallow clone,
> +	partial clone, and sparse checkout to make working with large repositories
> +	easier, and there is active development on making the monorepo experience
> +	better.
> ++
> +However, at a certain size, the performance of a monorepo will likely become
> +unacceptable _unless_ you use these features.  If you choose to start with a
> +monorepo and continue to grow, you may end up unhappy with the performance
> +characteristics at a point where making a change is difficult.  The performance
> +of using many smaller repositories will almost always be much better and will
> +generally not necessitate the use of these more advanced features.  If you are
> +concerned about future performance of your repository and related tools, you may
> +wish to avoid a monorepo.
> ++
> +Ultimately, you should make a decision fully informed about the potential
> +benefits and downsides, including the capabilities, performance, and future
> +requirements for your repository and related tools, including your hosting
> +platform, build tools, and other programs you typically use as part of your
> +workflow.
> +

Does this need some comparison, or link, with sub-module methods and
issues? Such as the nested sub-module problem, the distinction between
active sub-modules and quiescent sub-modules (e.g. libraries Vx.y.z)?

As an aside, I don't think we provide any background to the Git
philosophy that frames some of these issues.

-- 
Philip