Tao of Git Submodules 2
During my exploits to spread the Gospel of git-managed websites, once a great crisis broke out. A user threatened me he would return to MKS Source Integrity.
Now, such an event would shake the foundations of the entire Open Source Free Software movement. Richard Stallman would put sackcloth upon his loins. Linus Torvalds would rend his clothes. I would mourn for many days and my soul would refuse to be comforted.
Time to do something. Or rather, time to think.
I had actually been wondering, why Git’s submodule interface is so inconsistent. There is a –recursive clone, but there is no recursive option for any other remote operation. And then I was enlightened. Of course
There Is No Recursive Push
How could there be? The entire concept of submodules is based on universally read-accessible subprojects inserted into your superproject. You reuse one from gnu.org, another from the Moon, and some from Alpha Centauri. Write access for these is not guaranteed, it’s the privilege of a chosen few.
So what to do with your git-managed remote website? There are two options.
1. The remote repo has a detached worktree (repo in ~, website in /var/www)
Set up remotes and server-side post-receive hooks to check out for the subprojects.
You may want to add a pre-commit hook to the superproject pushing the submodules first.
2. The remote repo is in the website worktree
Add “git submodule update” to the post-update hook on the server side.
This assumes the server is able to access the submodule URLs.
