From: Jonathan Nieder <jrnieder@gmail.com>
Date: Thu, 11 Nov 2010 19:00:53 GMT
Subject: Re: [PATCH v3 2/3] Add the 'fetch.recurseSubmodules' config setting
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