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

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2016, 23:07 UTC
Message-ID: <xmqqfutw85oz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYKbef7DTkmE3Vf3C=PLfgB3xf0ikVKHFUfQ8+KkgGHPg@mail.gmail.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.