The guideline is simple, in regards to Git limits:
- one repo per project
- a main project with submodules.
The idea is not to store everything in one giant git repo, but build a small repo as a main project, which will reference the right commits of other repos, each one representing a project or common component of its own.
The OP Paul Alexander comments:
This sounds similar to the “externals” support provided by subversion.
We tried this and found it extremely cumbersome to constantly update the version references in the externals since the projects are developed concurrently with dependencies on each other. Is there another option??
@Paul: yes, instead of updating the version from the main project, you either:
- develop your subprojects directly from within the main project (as explained in “True Nature of submodules”),
- or you reference in a sub-repo an
origintowards the same sub-repo being developed elsewhere: from there you just have to pull from that sub-repo the changes made elsewhere.
In both case, you have to not forget to commit the main project, to record the new configuration. No “external” property to update here. The all process is much more natural.
Honestly, this sounds like a real pain and anything that requires developers to do something manually each time is just going to be a regular source of bugs an maintenance.
I suppose I’ll look into automating this with some scripts in the super project.
I replied:
Honestly, you may have been right… that is until latest Git release 1.7.1.
git diff and git status both learned to take into account submodules states even if executed from the main project.
You simply cannot miss submodule modification.
That being said:
- submodules are different from SVN externals: see “Why are git submodules incompatible with svn externals?”
- managing submodules can be tricky: see “How exactly does git submodule work?”.