How do I "commit" changes in a git submodule? [duplicate]

I have, in my naivety, set up a git submodule and treated it like a Subversion external - i.e. it's now full of changes that I've just realized haven't been committed or pushed anywhere.

Is there some easy way to commit/push the submodule changes back to the upstream repo? And what's the recommended technique in Git for doing simultaneous development on separate (but linked) repositories in this way?

Solution 1:

A submodule is its own repo/work-area, with its own .git directory.

So, first commit/push your submodule's changes:

$ cd path/to/submodule
$ git add <stuff>
$ git commit -m "comment"
$ git push

Then, update your main project to track the updated version of the submodule:

$ cd /main/project
$ git add path/to/submodule
$ git commit -m "updated my submodule"
$ git push

Solution 2:

Note that if you have committed a bunch of changes in various submodules, you can (or will be soon able to) push everything in one go (ie one push from the parent repo), with:

git push --recurse-submodules=on-demand

git1.7.11 ([ANNOUNCE] Git 1.7.11.rc1) mentions:

"git push --recurse-submodules" learned to optionally look into the histories of submodules bound to the superproject and push them out.

Probably done after this patch and the --on-demand option:

--recurse-submodules=<check|on-demand|no>::

Make sure all submodule commits used by the revisions to be pushed are available on a remote tracking branch.

• If check is used, it will be checked that all submodule commits that changed in the revisions to be pushed are available on a remote.
  Otherwise the push will be aborted and exit with non-zero status.
• If on-demand is used, all submodules that changed in the revisions to be pushed will be pushed.
  If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status.

This option only works for one level of nesting. Changes to the submodule inside of another submodule will not be pushed.

Solution 3:

$ git submodule status --recursive

Is also a life saver in this situation. You can use it and gitk --all to keep track of your sha1's and verify your sub-modules are pointing at what you think they are.