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