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