Jeff King <peff@xxxxxxxx> writes: > In an ideal world the user do: > > git submodule add git://host/repo.git path > > which adds the gitlink and the .gitmodules entry. But it doesn't seem > unreasonable for somebody unfamiliar with submodules to do: > > git clone git://host/repo.git path > git add path > > This does add the entry as a gitlink, but doesn't write any sort of > .gitmodules entry. I actually would think that is a perfectly valid state. In that original repository pair (i.e. the superproject with a submodule without an entry in .gitmodules), as long as the configuration in the submodule repository "path/.git/config" has necessary remote definitions, "git push/fetch --recursive" etc., should also be able to work without having to consult .gitmodules at the top-level superproject, I would think. > With the old code, cloning the repository (either by > another user, or in our case during a Pages build), a recursive clone or > submodule init would complain loudly. But now it's just quietly ignored. > Which seems unfortunate. Of course, if such an original superproject gets pushed to a publishing location and then the result is cloned, without an entry in .gitmodules, no information "git submodule" can use to work on that "path" exists in that clone. I would say it is OK to leave it as-is when going "--recursive" (what you called "inactive because it does not even have a .gitmodules entry). But even in such a clone, once the user who cloned learns where the submodule commit that is recorded in the superproject's tree can be obtained out-of-band and makes a clone at "path" manually (which replicates the state the original repository pair), things that only need to look at "path/.git/config" should be able to work (e.g. "git fetch --recursive"), I'd say.