There are git options for managing these difficulties like:
git config --global submodule.recurse true
https://git-scm.com/book/en/v2/Git-Tools-Submodules search for "git config"
git config --global submodule.recurse true
https://git-scm.com/book/en/v2/Git-Tools-Submodules search for "git config"
This is git in a nutshell. Most defaults are very bad, and so using git from the command line is an exercise in learning which flags to set to achieve a sane workflow.
Though it’d be nice if `git commit’ supported it too and just did a `git submodule foreach git commit …`.
I've never thought of doing commits in submodules. We use them a lot at work but only in a "import a specific revision of this other repo into our repo" sense, if we needed to make changes we would do them in the repo that the submodule points to and then just update the ref that the submodule points to.
What's your use case for making and committing changes inside the submodule tree?
The use case being that you can work on and update some independent system/repo while getting real-time feedback on how the changes interact with the system as a whole.
doing a quick fix that changed an API and had to be done in backend and frontend and in the main.
though it's quite similar to todays gitops flow, but with submodules :)
When working on both, it's really annoying to have to commit to a dependency's repo, push, and pull down in the dependent repo. If you do the commit in the submodule, it's just immediately available...and you can still have whatever remote to push to. So it just cuts down on the number of checkouts you have to have.
For our purpose that's definitely worse; the submodule is supposed to be a pointer to a specific tree, with that tree being the same for all developers. If we want to change the tree that is pointed to, we should commit and push a change to the submodule ref.