On Fri, Jun 9, 2017 at 7:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. me too. But on the other hand I do not want to offend non-submodule-gitlink-users too much. So maybe: $ git add <gitlink> # Adding a raw gitlink to the index, # in case you want to use a submodule, # use add a .gitmodules file or use 'git submodule add' > 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. but these are the 2nd step, clone fails first. > >> 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. But the user would never learn, because $ git clone --recurse-submodules ... does not complain, but put an empty dir instead. > >