On Thu, Jan 21, 2016 at 2:18 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Stefan Beller <sbel...@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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
