Stefan Beller <[email protected]> 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. 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
