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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 11, 2010, 19:00 UTC
Message-ID: <20101111190053.GH16972@burratino>
In-Reply-To: <7v1v6rhfut.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> 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, that makes some sense to me. Except wouldn't it be a single configuration item? "These submodules should be checked out in all but unusual situations, so check them out automatically and keep them updated."

Maybe a person setting this to false actually means "This submodule has its url set to a repository that is updated very frequently, and most updates are not relevant to the superproject." Unfortunately, I think the result would be a poor user experience: when an update comes that _is_ important to the superproject, what happens?

 $ git fetch
 ... go on plane ...
 $ git merge @{u} && git submodule update --no-fetch --recursive
 [...]
 fatal: reference is not a tree: f1c596a3895643d0969a15b8e945bf0c0072e470

Hmm. I think in that scenario a better solution would be to point the submodule url point to a project-specific clone that is updated less frequently.

What am I missing?

Jonathan