Hi, On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote: > > On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote: > >> Heiko Voigt <hvoigt@xxxxxxxxxx> 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). Sorry that I forgot to answer to this. I am not sure what you mean by "the semantics change". This patch does not change any existing behavior. I rather see this as an extra way to specify the default behavior of what happens on submodule update. If people do not use it there will be no expectations broken. Another change I am thinking of (which would definitely need an entry in the release notes) is to change submodule foreach to iterate over all gitmodule entries in the index/HEAD/worktree (not sure yet) instead of "just entries that are in .git/config". What do you think? Cheers Heiko -- 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