Junio C Hamano <gitster@xxxxxxxxx> 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.
