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

[Jeff King <peff@peff.net>]

On Sat, Jun 10, 2017 at 11:10:11AM +0900, Junio C Hamano wrote:

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

Certainly I think it _could_ be a valid state. But traditionally it
caused "clone --recursive" to barf. And from what Stefan and Brandon
have said, we are moving in the opposite direction entirely, with
.gitmodules becoming the source of truth.

I could see arguments for going in either direction (gitlinks versus
.gitmodules as source of truth for submodules). But it bothers me that
it's so easy to create a state that will behave in a confusing manner.

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

I agree that's possible. But I think one problem that our submodule
support has traditionally suffered from is leaving open what is possible
and not making any policy choices, or providing any guidance. Unless you
are an expert user who plans on circumventing the usual "git submodule"
process (and having your collaborators do so, too), I don't think you'd
ever want to do a "git add" as above. You want "git submodule add".

Allowing both is not in itself wrong.  But because we provide no
guidance for the expert route, it's easy to shoot yourself in the foot
and not even realize it. Which is why I suggested a warning and not
forbidding the operation. Or better still, an advise() block that tells
you how to recover (probably "git submodule add", though it might need
to learn to handle already-present gitlinks). And which can be disabled
if you really are an expert user.

-Peff