On Mon, Aug 29, 2016 at 2:03 PM, Uma Srinivasan <usriniva...@twitter.com> wrote:
> On Mon, Aug 29, 2016 at 1:03 PM, Junio C Hamano <gits...@pobox.com> 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.