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

Hi,

On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:

quoted

On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:

quoted

Heiko Voigt [off-list ref] 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