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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.  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.