I'm working on a git project relying on a git submodule pointing to an outdated commit which is not usable for the main project. After successfully updating the master branch of this submodule to the commit I would like to use, grabbed from an external repository, I go back to the parent of the submodule, the main project, and issue git submodule update as I understood this is the correct way to make the parent know about the update. However, if I now move back to the submodule folder I see I'm on (no branch) which is still the branch of the old unusable commit. In the submodule I do see the updated master branch to version I would like to use. This leads me to think that I did not manage to correctly update the submodule to my preferred commit. Or should I not update the submodule from the main project?
Thank you!
It's a simple mistake:
After successfully updating the master branch of this submodule to the commit I would like to use, grabbed from an external repository, I go back to the parent of the submodule, the main project,
Good so far, but then:
and issue
git submodule update
No: this yanks the submodule back to the recorded old snapshot.
What you want to do after getting the submodule into the desired state is go back into the superproject as you did, and then run:
git add path/to/submodule
This updates your index / staging-area, in the same way that git add copies a regular file into your index.
Eventually—when all files and submodule hashes are correct—you should then run git commit to make a new commit. The new commit saves the new snapshot, which includes the new hash ID for the submodule to be in "no branch / detached HEAD" mode on whenever this commit is the one checked out.
Note that, unlike with regular files, checking out a commit doesn't put the submodule onto the correct commit; it's only git submodule update that does that.