Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote: >> Heiko Voigt <hvoigt@xxxxxxxxxx> writes: >> >> > On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote: >> >> Heiko Voigt <hvoigt@xxxxxxxxxx> writes: >> >> > We have been talking about loose submodules for some time: >> >> >> >> Also before introducing a new terminology "loose submodule", please define >> ... >> That sounds like a good thing to do. > > I discovered that I only talked in the cover letter about the term > 'loose'. Since that will not go into any commit I guess we can keep the > series this way? Yes, except that I do not have a clear answer to my other half of the question in the same message you omitted from your quote. >> 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). -- 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