Re: [PATCH 0/2] Add an update=none option for 'loose' submodules

> > On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:
> >> Heiko Voigt <hvoigt@hvoigt.net> writes:
> >> What I usually do is say "submodule init" without any extra option once.
> >> That will register all submodules from .gitmodules in the config. Now
> >> when I say "submodule update" all submodules would be cloned. In the
> >> case of recursive submodules actually
> >>
> >> 	git submodule update --init --recursive
> >>
> >> is the only command which can get you really everything in one go.
> >>
> >> Do you think the "submodule init" behavior is wrong? If so I think its a
> >> bit late to change this since people using submodules (me included)
> >> already have got used to it.
> >>
> >> With this config variable all submodules will still be registered to
> >> .git/config on "submodule init" but "submodule update" will skip those
> >> submodules.
> >
> > Ok, that sort-of makes sense, but we have been using "do we have the
> > submodule registered in the .git/config of the superproject?" to decide
> > "does the user interested in having a checkout of the submodule?" (I think
> > in the ancient days it was "do we have .git in that submodule directory?"
> > that decided it, but we dropped that because it won't work when switching
> > branches that has and does not have the submodule in superproject).
> >
> > It is somewhat worrying that some parts of the system may still be using
> > that old criteria "do we have it in .git/config of the superproject?" to
> > decide if the user is interested in the submodule. If so they need to be
> > updated to take this new semantics "do we have it in .git/config without
> > its submodule.$name.update set to none" into account. We would probably
> > need to have a paragraph in the release notes to warn about the semantics
> > change (which I tend to agree with you that it is a good one).