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 wrongthis 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 Windowsthe 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
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 symlinksCygwin and NTFS native symlinks requirements
