I'm making an integration project that includes submodules for various
components and each day makes a commit in the super-project with all
desired versions of the components. Because many components come from
Subversion repositories, I typically import them directly using git
svn clone, and then add the submodule using a relative path, such as
git submodule add ./some_module.
The idea is that at any super-project checkout will automatically fetch
all the correct versions of the components. This seems the ideal use of
submodules. For the most part, this works correctly.
However, when creating new submodules, moving submodules around, or
deleting submodules, there are problems checking out old versions
of the project. Basically, when I delete a submodule, git seems to force
me to remove the entire subdirectory including .git files, which essentially
gets rid of all its history too. If I would leave the .git files around,
I wouldn't be able to treat the subdirectory as a regular subdirectory.
Probably I could work around the issue by having separate independent
git repositories for each component, so there would be no conflict
between working tree and submodule repository. However, this makes it
much more cumbersome and script-intensive to do automatic nightly updates
of all component repositories and generally results in an extra level of
indirection.
If submodules would just be able to share the master .git directory
for their storage, it would seem that most of these problems would
disappear. It would still be possible to selectively initialize and
clone submodules; resulting packs would just share the same .git
directory. They might even be in their own subdirectories of .git,
they just need to be found for resolving submodule references.
With this improved organization it would be trivial to check out
any old version of the super project, because the commits referenced
by these versions would be easy to find.
It seems that currently git itself, apart from its configuration files,
really adheres to the "content is king" credo, but for submodules we
are thrown back to making path names special. We have persistent identities
for submodules and they cause problems.
My question: how do I manage submodules without falling in these traps?
-Geert
PS. Below is a script that shows a problematic chain of events to replace
a submodule by a regular subdirectory.
git init super
cd super
git remote add origin $(pwd)
git init sub
cd sub
echo submodule>txt
git add txt
git commit -m "Initial subproject revision"
cd ..
git submodule add ./sub
git commit -m "Initial super project commit"
# The following line is problematic, but what to do instead?
rm -rf sub
git rm sub
mkdir sub
echo subdirectory>sub/txt
cd sub
git add txt
git commit -m "Sub is now a subdirectory" txt
cd ..
# Repository all done now, let's go back to last revision
git checkout HEAD~1
git submodule update
cd ..
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html