That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule).

Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:

1. Change the file

2. Commit within the submodule

3. Push the submodule

4. add the submodule change in the outer repo

5. commit in the outer repo

6. push the outer repo

In the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.

You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.

git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.

To add to this, you can add in your .gitmodules the name of the branch that the --remote flag will follow. It just works.

You can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.