Re: [PATCH 0/4] Submodule Groups

From: Stefan Beller <sbeller@google.com>
Date: Jan 21, 2016, 22:30 UTC
Message-ID: <CAGZ79kYVE7a=kXi__+Y3C7cuQUhY78o0unuw7vU4hrO71q1dwA@mail.gmail.com>
In-Reply-To: <xmqq37tqy3t4.fsf@gitster.mtv.corp.google.com>

On Thu, Jan 21, 2016 at 2:18 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> Instead of having a submodule -> set assignment, we could do it the
>> other way round:
>>
>>      [submodule "gcc"]
>>          ...
>>
>>      [submodule-set "default"]
>>         submodule = gcc
>>         submodule = foo
>>         submodule = by/path/*
>>
>> This may be more handy from our perspective (while designing it and
>> writing the code),
>> but I'd assume this is less useful for the user. How often does a user ask:
>> "How many/Which submodules are in $GROUP" as opposed to "What about
>> submodule foo,
>> is that part of group $GROUP?"
>
> I suspect that we will end up needing to support both styles.

I think having both is bad as it may contradict each other? What is supposed to happen here:

     [submodule "frotz"]
         group = default

     [submoduleGroup "default"]
         member = !:frotz

Initially I disliked your proposal of : and * to indicate name and groups, but the example you gave is very clear and understandable on the syntax level.

Show 22 quoted lines

>  The
> latter style is easier when you want to express a larger set as a
> collection of groups, e.g.
>
>     [submodule "gcc"]
>         group = development-tools
>
>     [submodule "emacs"]
>         group = editors
>
>     [submodule "frotz"]
>         group = games
>
>     [submoduleGroup "default"]
>         member = *development-tools
>         member = *editors
>         member = :frotz
>         member = !*xyzzy
>
> might be a way to say "the default group includes everything in the
> 'development-tools' or 'editors' group, plus 'frotz' module, but do
> not include modules in the xyzzy group" or something like that.

> I forgot to say that I personally do not think we need to support
> such synthetic groups from day one.

So groups of groups, we discovered recursion today. :) Having this discussion makes me realize, the groups handling logic will be more complex than I anticipated for the first RFC patch series.

The two basic questions the logic has to answer is:
 * Give me all the submodules that fit these specifiers (i.e. the
    --init-submodules collection from clone)
 * Given submodule X, does it fit the specifier ( a new uninitialized
    submodule during a later update)

The second question can be answered by answering the first question and then checking if X is in the set. However that may be not the most efficient solution.