I am migrating a 10-years-old big CVS repository to Git. It seemed obvious to split this multiple-projects repository into several Git ones. But the decision-makers are used to CVS, therefore their point of view is influenced by CVS philosophy.

To convince them to migrate from one CVS repo to different Git repositories I need to give them some arguments.

When I speak with mates working on Git repo for years, they say that using multiple Git repo is the way to use Git. I do not know really why (they give me some ideas). I am a newbie in this field so I ask here my question.

What are the arguments to use multiple Git repositories instead of a single one containing different applications and libraries from different teams?

I have already listed:

• branches/tags impact the whole Git repository files => pollutes other team projects
• 4GB limit Git repo size but this is wrong
• git annotate may be slower on bloat Git repo...

• Eamon Nerbonne has noticed the related question:
  Choosing between Single or multiple projects in a git repository?
• The reason the team managers finally have accepted the split: the single Git repo (550 MB) was requiring 13 minutes to be cloned on Windows _{(one minute on Linux)}.
• The bloat CVS repo split in 100 Git repositories:
• each dead apps in one repo
• each stabilized library in one repo (source code almost never changed any longer)
• related apps/libs kept together in one repo
• moved large files not used for compilation (config...) to other repos (Git does not like large files)
• skipped other unrelevant files (*.jar, *.pcb, *.dll, *.so, *.backup ...)
• Successfully installed the repo tool used by Android Open Source Project in order to handle all these Git repos:
• easy installation on Linux
• more difficult on Windows because of Cygwin and NTFS native symlinks requirements