Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote: >> Heiko Voigt <hvoigt@xxxxxxxxxx> writes: >> >> > If a submodule is used to seperate some bigger parts of a project into >> > an optional directory it is helpful to not clone/update them by default. >> >> Sorry if I am slow, but I do not get this. >> >> I thought unless you say "submodule init" once, a submodule you are not >> interested in should not be cloned nor updated at all. If that is not the >> case, isn't it a bug to be fixed without a new configuration variable that >> fixes it only when it is set? > > 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). >> > We have been talking about loose submodules for some time: >> >> Also before introducing a new terminology "loose submodule", please define >> it somewhere. It feels confusing to me that a normal submodule, which >> shouldn't be auto-cloned nor auto-updated without "submodule init", needs >> to be called by a name other than simply a "submodule" but with an >> adjuctive "loose submodule". > > Thats why I avoided talking about it in the docs. For the commit message > I thought it would be kind of intuitive but I can update the commit > message so that it becomes more clear. That sounds like a good thing to do. Thanks. -- 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