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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html