Am 11.11.2010 20:00, schrieb Jonathan Nieder:
quoted text
> 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."

Hmm, but we have at least three modes of how to update them:

1) Never fetch the submodule (to get new commits the user has to run
   "git fetch --recurse-submodules" by hand)

2) Fetch the submodule each time you fetch the superproject (Which is
   really handy when you do development in the submodule too but can
   be really inconvenient when you don't)

3) Update submodules only when new recorded commits are fetched in
   the superproject (This mode is not added with the current patch
   series but will be in one of the next)

So you would need a config option for that anyway, no? And that is why
I'd rather like to have a separate fetch option to control that behavior
instead of an implicit "if-it's-to-be-checked-out-fetch-it-too" approach.


quoted text
> 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?

That situation should be handled by method 3) above which was proposed
for such a use case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html