I would pay $20 if git would disallow committing from within the submodule directory (single source of truth), because it makes it so easy to forget a git push from within that submodule and now "works on my machine," but "special wtf edition!"

I've convinced that the real problem with submodules is basically the UI. In particular, the defaults are terrible. You can ask it to block pushing if there are unpushed submodule commits with:

    git config push.recurseSubmodules check

Or you can make it push automatically by replacing "check" with "on-demand".

You may also find it helpful to make various commands automatically apply to submodules with:

    git config submodule.recurse true

Thank you, that push.recurseSubmodules=check is the knob I was looking for, and wish it were the default

I got excited about the submodule.recurse=true one, but at least for "git status" it did not descend into the submodule the same way that "git submodule foreach git status" does

You could put a failing script (printing a message and exit 1) at .git/hooks/pre-commit in the submodule[1] (note that this is by-passed if you give --no-verify to git commit). Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams. I guess having that functionality in the core as a warning might not be a bad idea (I'm not a Git developer, you'll have to ask them).

[1] or rather ../.git/modules/"$submodulename"/hooks/pre-commit, depending on how the submodule was added

Last I checked, one cannot write any such silliness during clone, so it would require documentation or something out of band to fix it on every junior developer's workstation, and thus doesn't help as much as if there was a `git config --global commit.allowSubsubmodle false` or whatever

> Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams

(a) those scripts are most certainly not called .sample (b) it was fast enough to set up a local test case and (as expected) each repo (outer and "inner" submodule) carry their own git hook setups and `echo "exit 1" > .git/hooks/pre-commit` does stop top level commits but does nothing for the inner repos

> .sample

Yes, I carelessly copy-pasted the path.

And yes, as I said it would probably be a good idea to have a feature like that in the core. -- Ah, I see the other reply, so it's done. I generally recommend asking such questions on #git on IRC, someone will know the answer if a feature already exists.

Are you saying submodule SHA was updated in the parent repo, but the new submodule commit which the parent repo is now pointing to was never pushed?

I haven't experienced that scenario before but it seems like there'd be an obvious git error?

No, the opposite:

    git clone --recursive some/repo.git
    cd repo/subrepo
    sed -i"" s/hello/goodbye/ README.md
    git commit -am 'lololo'
    cd ..
    git commit -am'subrepo with *local* sha reference'
    git status  # everything is clean!

now that I know that can happen, running `git submodule foreach git status` will surface the "your branch is ahead of" magic text that indicates what has gone on, but it would be tons better if the system understood what was happening and didn't allow such a bad outcome