This question already has an answer here:
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 (
- Successfully installed the
repotool 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