Re: [PATCH 3/4] submodule update: Initialize all group-selected submodules by default

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

> "submodule.$name.group" to be found in .gitmodules, maybe overwritten in
> .git/config tells for each submodule its memberships of groups.
>
> "submodule.group" should be found in .git/config only, to tell some time
> after cloning which group selection was made, such that we can check
> if new submodules need to be initialized (or even automatically removed).

Ahh, it wasn't clear that was what you were trying to do.  If that
is the case, then ...

>     "git submodule update" may initialze and fetch new modules if the
>     .gitmodules file changed their view of what "default" is.
>
>>  The name of the operation, i.e. what is to be done to the
>> chosen modules, should be orthogonal, so I do not think you should
>> have "submodule.autoinitgroup" or somesuch.
>
> I agree there.

... I do not agree that the name of "submodule.group" variable
should be neutral to the operation that is done to the groups of
submodules named by the variable at all.

You are recording the criteria to choose a set of submodules there
in the configuration, with a plan to keep doing something to them
(e.g. "they will never be left uninitialized, i.e. initialied if a
new submodule is added to the set").  The name of the configuration
must have something that tells what that "something" is, in order to
(1) hint the purpose of specifying the group selection criteria
there, and (2) allow different selection criteria to keep doning
another kind of something to them and distinguish these two group
selection criteria.

E.g. "submodule.autoInitialize = *default !:foo" may mean all the
modules in the default group (now or added in the future) except the
module with name 'foo' will be initialized as needed, while
"submodule.autoDistim = *optional" may want to be defined to allow
the system to automatically distim (whatever that operation is that
will be added to Git in later versions) the modules in the optional
group.

> I am hoping we can put that in shorter options, such as
>
>     clone --init-module=A --init-module=\*B --init-module=/C \
>         --remember-init-for-tracking
>
> whereas:
>
>     --remember-init-for-tracking: Submodule groups which are given
> to clone will be remembered, such that each invocation of "update"
> will make sure that group is fully there, i.e. new submodules in
> the group will be initialized before updating.

Is there a need for --no-remember-init-for-tracking?  I do not think
it would be useful.

When the upstream adds a new module and defines it to be part of the
default group _after_ you cloned with --init set to 'default', and
you do not need that new module, at that point you can tweak your
submodule.autoInitialize definition to exclude that new module.

Tweaking submodule.autoInitialize definition to contain nothing
after cloning with --init because you do not want the autoinit
criteria kept in the resulting repository is merely a special case
of that.

So I do not think --remember-init-for-tracking is necessary.  Just
make it _always_ on and be done with it, I would say.