The tag is actually a human-readable version of a commit and when you add a submodule to a project, the project that you've added it to will store the state of the submodule at that commit hash. It doesn't point at HEAD
but rather the exact point in time commit when the submodule was added.
For example, game-music-emu @ 21a064e
is at the exact commit of 21a064e
, this is how submodules work by default.
If the commit exists in the default (e.g. master
) branch, the --depth 1
should get you just the commit history from the tag you are looking for. On the other hand, the default behavior is to bring with it all of the commit history from the default (e.g. master
) branch, this is why the shallow, or --depth 1
is needed as part of the submodule command. This is just how git repositories are cloned by default.
You can save the commit your submodule is currently on by using git add path/to/submodule
. Note, the submodule and the parent folder in which it lives are two separate repos!
Note... if the commit exists on another branch, git submodule add
also supports the --branch
option and the documentation states the .gitmodules
file will contain an entry for branch = somebranchname
, however in testing, git 1.9.1 does not seem to honor this and the default (e.g. master
) branch is used regardless.
So to answer the question, to make this faster for your developers, write a helper script into your build system to pull in your submodules at a shallow depth automatically using the git submodule
combined with the --depth
parameter, or alternately update your documentation to specify --depth 1
so speed up clone times.
Lastly, git submodule
also supports foreach [--recursive] <command>
option which will allow custom commands on each submodule.
Here's an example I'm working on in cmake to lazy fetch at a shallow depth for an entire project.
https://gist.github.com/tresf/263ea897036fa762674d489c8d457d68