Re: [PATCH v3 2/3] Add the 'fetch.recurseSubmodules' config setting

From: Jens Lehmann <jens.lehmann@web.de>
Date: Nov 12, 2010, 11:40 UTC
Message-ID: <4CDD27B6.3070907@web.de>
In-Reply-To: <7v1v6rhfut.fsf@alter.siamese.dyndns.org>

Am 11.11.2010 19:31, schrieb Junio C Hamano:

Show 13 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
>>> "fetch.recurseSubmodules" is only read from .git/config. The one read
>>> first from .gitmodules and then from .git/config is the per-submodule
>>> setting "submodule.<name>.fetchRecurseSubmodules" added in 3/3.
>>
>> Sorry for the nonsense.  Would it be easy (or desirable) to make
>> _that_ one not be read from .gitmodules?
> 
> I think the motivation behind having a way to read it from .gitmodules is
> so that project can suggest the default for convenience (e.g. "almost
> everybody who interacts with this project wants these submodules checked
> out and kept updated").

Yes, and to achieve that it should /not/ be necessary to run a "git submodule sync" manually afterwards to activate those changes.

Jonathan, I think when we allow upstream to configure which submodules are to be cloned and checked out by default (which seems an option almost everyone likes to have), doesn't it make sense to let upstream set a default which submodules should be fetched too (so that new commits there can be checked out recursively later)? I would rather not like to do that implicitly just because a submodule is configured for recursive checkout ...

Show 12 quoted lines

> Traditionally the suggestions kept in .gitmodules were propagated to the
> config when the submodule was initialized, and at runtime we read only
> from the config from then on without reading from .gitmodules, so that
> once the user decides to follow what the project suggests (or customize
> that away), the preference would stick to the repository.
> 
> That arrangement does not cater well to people who want to follow along
> whatever the project's suggestion of the day, so we might want to change
> things so that we if we find it in the config, we stop there and use what
> we found, otherwise we use what is in the in-tree gitmodules; I suspect we
> might require some changes to "submodule init" not to copy certain things
> to the config for that to work, though...

Right. But this would enable you to have branches where different sets of submodules are fetched, checked out and/or considered to make the superproject dirty depending on the topic the branch is for.