Am 23.08.2011 21:43, schrieb Heiko Voigt: > On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote: >>> 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. It might surprise people. E.g. when their old scripts don't work anymore as they did before because a submodule won't be populated or updated in the work tree even though it is present in .git/config. So I agree that this should be documented in the release notes so people can check if their expectations are still met. > 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". When changing the default I think we'll surprise a lot of users (imagine someone running a "git submodule foreach pwd" when some submodules aren't populated). But adding an option to "git submodule foreach" (and maybe others) to get the list of submodules from the index or HEAD might make sense (while I'm not sure parsing the work tree does, as you'll basically have to pick up any .git you find. AFAICS a submodule is defined either by an entry in the .gitmodules file, in .git/config or through a gitlink entry in a commit or the index. So maybe the third alternative to index and HEAD is to use those found in .gitmodules?). Could you describe a use case for that? -- 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