--cc Johannes Sixt
On Wed, Nov 25, 2015 at 9:35 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
>> [submodule "gcc"]
>> path = gcc
>> url = git://...
>> groups = default,devel
>> [submodule "linux"]
>> path = linux
>> url = git://...
>> groups = default
>> [submodule "nethack"]
>> path = nethack
>> url = git://...
>> groups = optional,games
>
>
> Yup. Do you want the user to select only a single group or do you
> plan to support selecting multiple groups at the same time too?
Yes you should be able to select multiple groups, such as
default+devel or alternatively default+games.
The logical OR is supported in this patch series (all submodules which are
in at least one of the specified groups,i.e. A OR B OR C ...)
>
>> and by this series you can work on an arbitrary subgroup of these
>> submodules such
>> using these commands:
>>
>> git clone --group default --group devel git://...
>> # will clone the superproject and recursively
>> # checkout any submodule being in at least one of the groups.
>
>
> Does this automatically configure the given group in .git/config, so
> that all future submodule related commands know about this choice?
> Me thinks that would make sense ...
It does. Internally it does
git config submodule.groups A,B
git submodule update --init --groups
whereas submodule update checks if the submodule.groups
value is set and if so operates on the groups only.
>
>> git submodule add --group default --group devel git://... ..
>> # will add a submodule, adding 2 submodule
>> # groups to its entry in .gitmodule
>
>
> Maybe '--groups default,devel' is easier to grok? Dunno.
I guess that makes sense.
>
>> # as support for clone we want to have:
>> git config submodule.groups default
>> git submodule init --groups
>
>
> Hmm, I doubt it makes much sense to add the --group option to "git
> submodule init". I'd rather init all submodules and do the group
> handling only in the "git submodule update" command. That way
> upstream can change grouping later without having the user to
> fiddle with her configuration to make that work.
Well if upstream changes grouping later, you could just run
git submodule update --init --groups
and get what you want?
>
>> # will init all submodules from the default group
>>
>> # as support for clone we want to have:
>> git config submodule.groups default
>> git submodule update --groups
>>
>> # will update all submodules from the default group
>>
>> Any feedback welcome, specially on the design level!
>> (Do we want to have it stored in the .gitmodules file? Do we want to have
>> the groups configured in .git/config as "submodule.groups", any other way
>> to make it future proof and extend the groups syntax?)
>
>
> Not sure what exactly you mean by "it" here ;-)
>
> Talking about what groups a submodule belongs to, an entry in the
> .gitmodules file makes the most sense to me. That way upstream can
> change submodule grouping or add new submodules with group assignments
> from commit to commit, and "git submodule update" will do the right
> thing for the superproject commit checked out.
>
> And I believe that the choice which group(s?) the user is interested
> should be recorded in .git/config, as that is his personal setting
> that shouldn't be influenced by upstream changes.
Right. I once discussed with Jonathan Nieder, who dreamed of a more
logical approach to the groups/sets of submodules. So more like set theory,
i.e. have a more complicated grammar: Get all submodules which are
in either A or B or (D AND E), but which are never in F.
So I'd imagine the groups are more like bit tags, and you can describe
a patterns you want.
I guess we want some more powerful eventually, so I asked this open ended
question there.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html