Are you supposed to commit changes to the parent when the submodules change?

Question

I noticed some strange behavior when working with submodules in Git, which is maybe not so strange to anyone with more experience than I. Well, what I am noticing is that whenever I make changes to any of my submodules, those changes seem to stage some sort of a change for a commit by the main repository that's containing all submodules... (not sure if that's very clear)

Am I supposed to be committing my main repository each time I make changes to the submodules? I have been doing it, but what happens if I don't?

Answer 1

Conceptually, a Git submodule is not a sub-repository that is included in the main repo. Instead, a submodule is a pointer to a specific revision of another repo. Apart from this pointer, all repos are entirely independent.

The parent repo only stores this revision pointer. So when you check out a different revision of a submodule (e.g. by committing changes), you also need to commit the new revision pointer value in the parent repo.

This means that using submodules is quite awkward to represent different parts of a project, and works much better when you are vendoring a different project into your source tree. I.e. view submodules as a very basic kind of dependency management system. You should commit a new submodule revision pointer to your main repo if you want to include a new version of that dependency.

When designing a Git repository architecture, this makes submodules unattractive for rapidly changing parts of the project, and better for fairly stable libraries with a slower release cycle. If different parts change together, keeping them together in a single cohesive repository is probably better.