Re: [PATCH 11/15] diff: ignore submodules excluded by groups

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

Stefan Beller <sbeller@google.com> writes:

> I am aware that other operations such as a build system would be glad to
> have the contents of the submodules there. But those would not use a
> restrictive default group?

The set of submodules you "init" to the working tree are the ones
that are interesting to you.  So once the tree is populated, you do
not ever have to look at the "defaultGroup" configuration.  You just
need to look at the working tree.

But there is a chicken-and-egg problem.  What should happen after
the initial clone, or you switched to a different branch in the
superproject.

The concept of "default" would help by limiting these "checkout to
reflect my interest to my working tree" step.

So "if the user inititializes a submodule and we detect that it is
not in the default, add it to the default configuration" pretty much
feels like a tail wagging a dog arrangement to me.

Then there is another interesting issue: what should happen when the
project added a submodule when you decided what your "default" set
should be and wrote it in your configuration already.  I suspect
that an idea similar to "the elaborate thing proposed (by whom I no
longer rememvber) in the ancient days" I mentioned earlier might
leads us to a nice solution.  When you define a default group, you
remember what the set of available submodules were, and tie your
choice to that "available set".

E.g. there may be submodules A, B and C in .gitmodules, and you
chose to record a "default" that contains only A and B.  The exact
way you chose does not matter; it could have been using labels, or
you may have explicitly named it.  When you record, you remember
that the decision of using A and B was made when A, B and C were the
available submodules.  Next time when you see .gitmodules talks
about A, B and D but no longer C, then instead of using the previous
"default" choice blindly, you ask.  If the user says it still is the
right "default" to use A and B, then you _also_ remember the set.
So that when the user switches between the state of the project with
submodules A, B and C (original) and A, B and D (updated), the user
does not have to answer the same question twice.