Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2017, 02:10 UTC
Message-ID: <xmqqbmpw4mpo.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170609231935.ysolxkiuhhpa3xrd@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> 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.