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

[Jens Lehmann <Jens.Lehmann@web.de>]

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?