Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

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

Junio C Hamano <gitster@pobox.com> writes:

> A few questions that come to mind are:
>
>  - Does "git add sub/" have enough information to populate
>    .gitmodules?  If we have reasonable "default" values for
>    .gitmodules entries (e.g. missing URL means we won't fetch when
>    asked to go recursively fetch), perhaps we can leave everything
>    other than "submodule.$name.path" undefined.
> ...
>  - ...  IOW, if "git add sub/" can
>    add .gitmodules to help people without having to type "git
>    submodule add sub/", then we can give exactly the same degree of
>    help without even modifying .gitmodules when "git add sub/" is
>    run.

Answering my own questions (aka correcting my own stupidity), there
is a big leap/gap between the two that came from my forgetting an
important point: a local repository has a lot richer information
than others that are clones of it.

"git add sub/" could look at sub/.git/config and use that
information when considering what values to populate .gitmodules
with.  It can learn where its origin remote is, for example.

And while this can do that at look-up time locally (i.e. removing
the need to do .gitmodules), those who pull from this local
repository, of those who pull from a shared central repository this
local repository pushes into, will not have the same information
available to them, _unless_ this local repository records it in the
.gitmodules file for them to use.

So, I think "git add sub/" that adds to .gitmodules would work
(unless the sub/ repository originates locally without pushing
out--in which case, submodule.$name.url cannot be populated with a
value suitable for other people, and we should continue warning),
while doing the same at look-up time would not be a good solution.