Ok that makes sense. Thanks much. Uma On Mon, Aug 29, 2016 at 2:09 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > On Mon, Aug 29, 2016 at 2:03 PM, Uma Srinivasan <usrinivasan@xxxxxxxxxxx> wrote: >> On Mon, Aug 29, 2016 at 1:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>> A top-level superproject can have a submodule bound at its "dir/" >>> directory, and "dir/.git" can either be a gitfile which you can read >>> with read_gitfile() and point into somewhere in ".git/modules/" of >>> the top-level superproject. "dir/.git" can _ALSO_ be a fully valid >>> Git directory. So at the top of a superproject, you could do >>> >>> git clone $URL ./dir2 >>> git add dir2 >>> >>> to clone an independent project into dir2 directory, and add it as a >>> new submodule. The fallback is to support such a layout. >>> >> Thanks for the reply. However, in this case.... >> >> git clone $URL ./dir2 >> git add dir2 >> >> how will "dir2" get ever get registered as a submodule? > > With a separate invocation of "git config -f .gitmodules", of course. > The layout to use gitfile to point into .git/modules/ is a more recent > invention than the submodule support itself that "git add" knows about. > The code needs to support both layout as well as it can, and that > is what the "can we read it as gitfile? If not, that directory itself may > be a git repository" codepath you asked about is doing.