submodules may or may not be annoying to use in a particular use case, but they work perfectly (in that they do what they do, not necessarily what you want/expe

submodules may or may not be annoying to use in a particular use case, but they work perfectly (in that they do what they do, not necessarily what you want/expect) from your comment, it sounds like you might not have the exact mental model of how they are expected to work? > then notice that the submodule lags behind the remote git repo the version of the submodule is staked to an exact commit hash in the main (outer) git repo. the use case is that the submodule should not "float" or change - if you check out a particular commit in the main repo, it will always point to this same submodule commit if you change the main repo branch, etc. you additionally have to ask to sync up the submodule for that new commit. i use: git submodule update --init instead, if you want to update the submodule to a new commit (e.g. to latest master branch), you have to enter the submodule, checkout the branch and pull. then in the main repo, you will add the submodule and commit it to link to the new submodule commit. so that can be annoying of course. but i find it works extremely well for submodules that are dependencies that you want staked to an exact version.