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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi brian,

thank you for this excellent idea to talk about monorepos.

On Wed, 20 Oct 2021, brian m. carlson wrote:

> 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

May I request taking out shallow clones? A user new to Git might think
that shallow clones are a sane way to clone a large repository. In
practice, this only makes sense for "throw-away" clones, though. As soon
as you fetch in such clones, performance will be so horrible that it is
frequently a better idea to start with a partial clone instead.

At the same time, I would like to swap in "sparse index" for "shallow
clone" because it _does_ have the best potential of all currently
discussed new features to improve performance with monorepos.

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

I would like to add a plug for Scalar here. Maybe we can link to this
"opinionated tool based on Git" here? I wouldn't ask if I didn't _know_
that it helps monorepo users out there.

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

I wish we had a good article to link to, here. Yes, it is a decision that
should be fully informed, and yes, this FAQ entry is not the place for a
thorough discussion of monorepos and how Git can be asked to handle them
more efficiently.

Do you know of any good resource that we could use here?

Thanks,
Dscho

> +
>  Merging and Rebasing
>  --------------------
>
>