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

From: Jeff King <peff@peff.net>
Date: Jun 10, 2017, 07:13 UTC
Message-ID: <20170610071342.gdmpgjqlho2xfvdt@sigill.intra.peff.net>
In-Reply-To: <xmqqbmpw4mpo.fsf@gitster.mtv.corp.google.com>

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

Show 22 quoted lines

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

Show 6 quoted lines

> 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