I would strongly advise against putting unrelated data in a given
Git repository. The overhead of creating new repositories is quite
low, and that is a feature that makes it possible to keep
different lineages completely separate.
Fighting that idea means ending up with unnecessarily tangled history,
which renders administration more difficult and--more
importantly--"archeology" tools less useful because of the resulting
dilution. Also, as you mentioned, Git assumes that the "unit of
cloning" is the repository, and practically has to do so because of
its distributed nature.
One solution is to keep every project/package/etc. as its own bare
repository (i.e., without working tree) under a blessed hierarchy,
like:
/repos/a.git
/repos/b.git
/repos/c.git
Once a few conventions have been established, it becomes trivial to
apply administrative operations (backup, packing, web publishing) to
the complete hierarchy, which serves a role not entirely dissimilar to
"monolithic" SVN repositories. Working with these repositories also
becomes somewhat similar to SVN workflows, with the addition that one
can use local commits and branches:
svn checkout --> git clone
svn update --> git pull
svn commit --> git push
You can have multiple remotes in each working clone, for the ease of
synchronizing between the multiple parties:
$ cd ~/dev
$ git clone /repos/foo.git # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...
You can then fetch/pull from each of the "sources", work and commit
locally, and then push ("backup") to each of these remotes when you
are ready with something like (note how that pushes the same commits
and history to each of the remotes!):
$ for remote in origin github memorystick; do git push $remote; done
The easiest way to turn an existing working repository ~/dev/foo
into such a bare repository is probably:
$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git
which is mostly equivalent to a svn import--but does not throw the
existing, "local" history away.
Note: submodules are a mechanism to include shared related
lineages, so I indeed wouldn t consider them an appropriate tool for
the problem you are trying to solve.
